Vulnerability summary
CVE-2026-42823 is an Azure Logic Apps improper access control flaw. The NVD summary is short: an authorised attacker can elevate privileges over a network. That matters because Logic Apps often sits between SaaS systems, internal services, queues and administrative workflows. A user or service principal with some access can become more dangerous if access keys or role assignments for a workflow are changed outside the intended change path.
The public record does not give a CVSS score, exploit chain or patch timeline in the summary used for this post, so this article does not invent one. The useful defender question is narrower: which Azure Activity Log events show access-control movement around Logic Apps resources, and how can a SOC separate normal maintenance from a privilege escalation attempt?
Why this belongs on the cloud audit plane
This CVE is not an endpoint telemetry problem. The action of interest happens in Azure Resource Manager and lands in Azure Activity Logs. A Logic App workflow can call APIs, pass data between services and hold access material used by connected services. If a principal changes workflow access keys or writes a role assignment against a Logic App resource, the control-plane log is the best place to see it.
The ATT&CK mapping is T1548, Abuse Elevation Control Mechanism. In this case the mechanism is not sudo, UAC or a local token trick. It is a cloud resource permission boundary. The rule therefore watches Azure Activity Logs for Logic Apps operations that touch access keys and role assignments. That is a good fit for cloud-hosted integration estates where Logic Apps connects Microsoft services, third-party SaaS and internal APIs.
There is one limitation worth naming. Azure Activity Logs can show that a sensitive control-plane operation happened, who requested it and which resource was targeted. They do not prove by themselves that the caller exploited CVE-2026-42823. Operators should treat a hit as a triage trigger, then check the caller identity, change ticket, workflow owner and surrounding sign-in history.
The CloudSigma rule
CloudSigma produced a high-severity Sigma rule for Azure Activity Logs. The rule has two parts. First, it narrows to operations that write or use Logic Apps access keys, write role assignments under Logic Apps providers, or write integration-account access keys. Second, it requires the target resource type to start with Microsoft.Logic/. That second condition keeps the rule on the Logic Apps surface instead of alerting on unrelated Azure role-assignment work.
id: be5a60f1-4785-4201-842f-78c92b8156d1
title: Azure Logic Apps Privilege Escalation via Improper Access Control
status: test
description: Detects privilege escalation attempts in Azure Logic Apps through improper access control mechanisms. Adversaries
with authorized access abuse Logic Apps' access control to elevate privileges over the network. This detection monitors
for operations that modify Logic App access policies or role assignments, which are common vectors for privilege escalation
in Logic Apps environments.
author: CloudSigma
date: 2026/05/15
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-42823
- https://attack.mitre.org/techniques/T1548/
tags:
- attack.privilege_escalation
- attack.defense_evasion
- attack.t1548
logsource:
product: azure
service: activitylogs
detection:
condition: selection_operation and selection_target_type
selection_operation:
operationName:
- Microsoft.Logic/workflows/accessKeys/write
- Microsoft.Logic/workflows/accessKeys/action
- Microsoft.Logic/workflows/providers/roleAssignments/write
- Microsoft.Logic/integrationAccounts/accessKeys/write
selection_target_type:
properties.targetResources.type|startswith: Microsoft.Logic/
falsepositives:
- Legitimate Logic App access key rotation during maintenance windows
- Infrastructure-as-Code deployments provisioning Logic Apps with role assignments
- Authorized administrators configuring Logic App access policies for legitimate business workflows
- Service principal operations during Logic App migration or disaster recovery procedures
level: high
The operationName allowlist does most of the work. It points at the operations a privilege escalation path would need to touch, rather than broad Microsoft.Authorization/roleAssignments/write activity across the whole tenant. The target-resource condition then binds the alert back to Logic Apps resources. That shape is what makes the rule usable for a cloud SOC: it is narrow enough to send to a queue without drowning analysts in every planned RBAC change.
Triage guidance for Azure operators
Start with the caller. If the actor is a deployment principal, compare the timestamp with the release window and the infrastructure change set. If the actor is a human administrator, check whether the same account also had risky sign-in events, new device enrolment, mailbox-rule changes or unusual source IPs. A Logic Apps privilege issue becomes more serious when it is paired with suspicious identity activity.
Next, inspect the workflow. Look at connectors, managed identity settings, callback URLs and recent workflow edits. A changed access key on a dormant workflow is more suspicious than the same event on an actively maintained integration account during a documented rotation. The false-positive list in the rule is practical: key rotation, infrastructure deployments, access-policy changes and migrations can all fire. Those are tuning inputs, not reasons to disable the detection.
For SIEM tuning, add exclusions around known deployment principals and maintenance windows, but keep the resource filter intact. If a team manages a small set of Logic Apps through Terraform or Bicep, scope the allowlist to that principal and repository-driven deployment pattern. Avoid a blanket exclusion for all administrators. That would remove the exact escalation path the rule is meant to catch.
Recommended actions
Deploy the rule at level: high in the SIEM that receives Azure Activity Logs. Keep the initial action as analyst review unless your environment has strict Logic Apps change windows and a well-maintained deployment-principal inventory. The expected hit rate should be low in a mature Azure tenant because Logic Apps access-key changes and role-assignment writes are not everyday user actions.
Pair the alert with two supporting checks. First, confirm whether the affected Logic App or integration account is internet-facing or connected to sensitive SaaS systems. Second, review recent sign-ins and token activity for the caller. CVE-2026-42823 is about privilege movement over the network; the useful response is to decide whether the control-plane event was routine administration or a step in a wider identity compromise.