An agent re-graded 9,967 high-severity cloud findings against the live environment and moved three quarters of them, most of them downward
Leon Goldberg and Gal Engelberg of Sola Security report an agent that re-derives a cloud security finding’s severity from evidence in the environment it was raised in, rather than accepting the fixed grade attached to the rule that raised it. Across 9,967 vendor HIGH findings drawn from two commercial cloud security platforms — 4,222 from one and 5,745 from the other — in eight production environments, 75.1% were re-graded: 58.5% downward and 16.6% upward, with 2,478 keeping the vendor’s grade. The static baseline they measure against is 599 vendor rules producing 99,073 failing findings, each rule carrying one severity regardless of the resource or the environment. The largest downgrade pattern, 32.3%, is inert resources attached to nothing or orphaned, and 49.0% of the agent’s verdicts rested on evidence beyond the flagged resource. Of 138 rules, 62 produced both downgrades and upgrades, and in 57 of those both happened inside a single environment. Read-only probes against eight AWS accounts re-read the deciding fact from the provider and confirmed 99.4% of the verdicts the probes could settle, a 95% Wilson interval of 99.1 to 99.6%, falling to 97.3% across every finding the probes could read and to 81.8% if every unchecked finding is counted as wrong. The authors state the limits themselves: 92% of the re-graded findings were on AWS, MEDIUM and LOW findings were out of scope, no incident data was used so exploitation likelihood was not assessed, recall was not measured, and whether the revised grades are correct is left open. The arXiv page read here carries no submission date, so this item is dated to the day the work was first reported.
New npm bound publishing trust to a repository name rather than its permanent id, and the researchers who found it say AI agents install about 70 packages a month on an ordinary endpoint
Bloom Security disclosed a flaw in npm’s Trusted Publishing, the feature that replaces long-lived publishing tokens with short-lived credentials. npm recorded the bound GitHub repository by its owner-and-name slug and did not check GitHub’s permanent numeric identifiers, so once a repository or owner was renamed, transferred or deleted, anyone could claim the freed slug, add a workflow file with the matching name and receive a publishing credential for someone else’s package — and a release published that way carries a valid provenance attestation naming the attacker’s repository. Bloom says no stolen credential was needed, and counts more than 1,500 exposed packages with over 10 million downloads in total and more than a million a month, naming none of them. It reported the issue through GitHub’s HackerOne programme on June 6 and GitHub validated it on June 9; after a July 8 reply and six unanswered follow-ups including a mediation request, GitHub announced the change on October 2, a spokesperson saying “Unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing.” Whether configurations that had already published were retroactively bound is not stated, and Bloom researcher Golan Myers says it is unknown whether the flaw was exploited. The AI element is blast radius rather than mechanism: Bloom argues coding agents widen it, estimating from its own telemetry that agents on a typical endpoint install about 70 packages a month and close to 350 on a developer machine, excluding dependencies and often without anyone reviewing the package or its maintainer — “developers are no longer the only ‘developer software’ consumers”.