Microsoft azure automation state configuration and 1 more name, elevation of privilege: 4 records, one defect family
Microsoft azure automation state configuration and 1 more name has been reported 4 separate times for the same kind of mistake, Elevation of Privilege, between 2021-09-15 and 2022-06-15. A defect family is our own grouping of the CVE corpus: every record naming one product and one weakness class, collected so a repeat is visible as a repeat. No public source publishes this, and what this page counts is how often this one product has gone wrong in this one way.
What this page is, and what it is not
The records are public. This grouping is not. No source publishes defect families, so we built them: every record in the corpus sorted by the product an authority named and the weakness class carried with it, 21316 families over 105586 records. This one holds every record that names Microsoft azure automation state configuration, dsc extension and carries Elevation of Privilege, matched character for character. We show the join because a grouping you cannot check is a grouping you should not cite.
That is 4 filings, between 2021-09-15 and 2022-06-15, landing on the same weakness class in the same product. At this count it is a repeat rather than a pattern, and the roster below is short enough to read in full. This is what we held on 2026-09-20.
A repeat is evidence about where to look. If you are reviewing Microsoft azure automation state configuration and 1 more name, the records below say which mistake has already been found more than once, which is the cheapest place a reviewer can start. If you are asking the vendor a question, a count under one weakness class is a better question than any single record is.
What this page cannot tell you is decided by what was joined. A product name and a weakness class settled membership, so those two values are the whole of what the page asserts. Records here may sit in the same line of code or in unrelated parts of the product, and we hold no value that separates those cases. A fixed version named in one record closes that record and says nothing about the others. And nothing here describes anyone's systems, because no value in this family connects a product name to an installation.
The names the authorities used
One spelling, used by every authority that filed one of these records: microsoft azure automation state configuration, dsc extension.
Family membership: held values. Joined on the product and weakness class the assigning authorities wrote, with no model involved.
What the records offer
1 of 4 records publish a fixed version. For the other 3, held sources name none.
3 records are listed by CISA with a required action, which carries a federal remediation deadline on its own page.
The earliest was published 2021-09-15 and the latest 2022-06-15. That span is how long this product kept producing this weakness, not how long any one record took to fix.
What this family was researched, not held
A Linux agent Azure installed for you, five times over
Open Management Infrastructure is the Linux management agent that several Azure services install on a customer's behalf, among them Azure Automation State Configuration and the Desired State Configuration extension. Wiz reported four flaws in it to Microsoft on 1 June 2021, a fixed build shipped on 8 September 2021, and the records were disclosed on 14 September 2021. The finding was as much about visibility as about code: Wiz said the agent's role inside Azure virtual machines was almost entirely undocumented, that the portal does not name it, and that customers had no clear guidance for checking or upgrading the version they were running. The same class returned in June 2022 with a fifth record, where the agent's secret was seeded from system time and could therefore be predicted. Writing in August 2022, Wiz said Microsoft had just enrolled the log, diagnostics and desired state configuration extensions in automatic extension upgrade, while several other services still did not support automatic updates.
The exposure travelled with the extension, not with the workload, so the inventory question is which extensions a machine was onboarded to and at what version. Whether it repairs itself without you depends on whether that extension is enrolled in automatic upgrade.
This grouping says these records read alike, all of them privilege escalation in the same management agent. It does not say they share a vulnerability or an estate, and it never means that fixing one of them closes another.
Written from wiz.io, wiz.io. Stated at medium confidence. Nothing in this box is a value the index holds, and none of it opens a receipt.
What this page does not cover
This is a family of records that read alike. It is not a shared vulnerability, not an inventory, and not a statement that one fix closes the rest. Each record's own state, its own dates and its own receipts are on its own page.
Grouped by shared product and weakness, not by shared vulnerability. Each record's own state is on its own page.
Everything this vendor has, including records outside this family:
4 records, read from the index as it stood on 20 Sep 2026. Every row opens the record it names, and every value on that record opens its own receipt.