[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fVYutBWNAgEnuKdeBN2YMK701TXslD2YpYDFSofJl11E":3},{"article":4,"iocs":45,"watch_terms":46,"solutions":47,"lesson":111},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"url":11,"image_url":12,"published_at":13,"ingested_at":14,"relevance_score":15,"entities":16,"category_id":27,"category":28,"article_tags":32},"aca046c2-fda9-4ffe-899e-553144770ca4","GitHub Actions Adds cache-mode to Limit Cache Poisoning Risk","github-actions-adds-cache-mode-to-limit-cache-poisoning-risk-d65f1f","GitHub has added cache-mode to GitHub Actions, a new setting that limits how workflows and jobs can access the Actions cache. It targets cache poisoning, the technique attackers used to compromise the Ultralytics PyPI package in 2024 and the TanStack npm packages in May 2026. Cache poisoning works because an entry written to the shared Actions cache in one context can be restored and run in another. An attacker who gains write access to a cache key that a trusted workflow later reads can plant malicious build artifacts or dependencies that execute with that workflow's permissions and secrets. In the TanStack attack, chained with a pull_request_target pwn request, the attacker published 84 malicious versions across 42 @tanstack\u002F* packages. Build provenance does not catch a poisoned cache. In its design proposal, GitHub noted that SLSA provenance and Sigstore signatures still pass on a build that restored a tampered entry, because the build ran where and when the workflow declared. The attestation covers the build's origin, not the integrity of the inputs it pulled from the cache. cache-mode Sets Cache Access Per Workflow or Job # cache-mode lets maintainers apply least-privilege access to the cache at the workflow or job level. It supports four values: read restores caches but blocks saves. This is the default for low-trust events such as pull_request_target. write restores and saves caches. This is the default for trusted events such as push. write-only saves caches but blocks restores. none blocks all cache access. Job-level settings override workflow-level settings, and the cache service enforces the mode. The setting also carries through reusable workflows, so a called workflow cannot receive more cache access than its caller granted. Declaring write or write-only for a low-trust event reintroduces poisoning risk, so GitHub adds a warning annotation when a declared mode grants write access. GitHub recommends none as a control for AI agent workflows. In the design proposal, it describes agent-driven workflows that act on issue or pull request text as a case that can execute untrusted input, the exposure behind the Cline compromise, where a prompt injection in a GitHub issue led to a suspected cache poisoning attack. Setting cache-mode: none removes the cache from that environment. GitHub Added write-only Based on Public Feedback # GitHub opened the cache-mode design in May 2026 with three values: read, write, and none. Security researcher Adnan Khan, whose cache poisoning research GitHub cited in the proposal, pushed for a write-only mode so a trusted branch can populate a cache without ever restoring from one. That value shipped in the final release. # GitHub shipped read-only cache defaults for most untrusted triggers in June 2026, so workflows that never configured caching were already blocked from saving poisoned entries through those events. cache-mode adds the configurable layer on top: per-job control, the none option, cache-service enforcement, and the cap on access through reusable workflows. It does not close the broader set of Actions risks. Workflows that check out untrusted code, run package lifecycle scripts, or mint OIDC tokens inside the runner remain exposed through the same paths seen in the TanStack attack and in GitHub's earlier checkout hardening. GitHub recommends granting each workflow or job only the cache access it needs, the least-privilege approach cache-mode is built to support.","GitHub Actions has introduced a new 'cache-mode' setting to combat cache poisoning attacks. This feature allows developers to control how workflows and jobs access the Actions cache, limiting the risk of malicious artifacts being injected and executed. The update addresses vulnerabilities exploited in the Ultralytics PyPI and TanStack npm packages.","GitHub Actions adds cache-mode to mitigate cache poisoning risks.","https:\u002F\u002Fsocket.dev\u002Fblog\u002Fgithub-actions-cache-mode?utm_medium=feed","https:\u002F\u002Fcdn.sanity.io\u002Fimages\u002Fcgdhsj6q\u002Fproduction\u002F4a065337259fb47679ce58052def102f2dfb0d2b-1672x941.png?w=1000&q=95&fit=max&auto=format","2026-09-16T19:36:23.9+00:00","2026-09-16T22:00:30.591109+00:00",8,[17,20,22,24],{"name":18,"type":19},"GitHub Actions","product",{"name":21,"type":19},"Ultralytics PyPI package",{"name":23,"type":19},"TanStack npm packages",{"name":25,"type":26},"GitHub","vendor","26b0b636-0e31-4db1-bffb-61bdf9f20a58",{"id":27,"icon":29,"name":30,"slug":31},null,"Supply Chain","supply-chain",[33,38,40],{"category":34},{"id":35,"icon":29,"name":36,"slug":37},"02371804-cf6d-4449-98de-f1a2d4d9b266","Tools","tools",{"category":39},{"id":27,"icon":29,"name":30,"slug":31},{"category":41},{"id":42,"icon":29,"name":43,"slug":44},"80544778-fabb-4dcd-aa35-17492e5dcf4f","Vulnerabilities","vulnerabilities",[],[25,18,21],{"controls":48,"vendors":105},[49,78],{"slug":50,"name":51,"problem":52,"products":53},"breach-attack-simulation","Breach and attack simulation","You only find out whether your security tools stop an attack when a real attacker tries.",[54,62,70],{"vendor_slug":55,"vendor_name":56,"vendor_logo":57,"product_slug":58,"product_name":59,"url":60,"description":61},"safebreach","SafeBreach","\u002Fvendor-logos\u002Fsafebreach.png","safebreach-validate","SafeBreach Validate","https:\u002F\u002Fwww.safebreach.com\u002Fvalidate-breach-and-attack-simulation\u002F","Breach and attack simulation with a large library of real attack methods, testing how well controls work across the whole attack chain.",{"vendor_slug":63,"vendor_name":64,"vendor_logo":65,"product_slug":66,"product_name":67,"url":68,"description":69},"pentera","Pentera","\u002Fvendor-logos\u002Fpentera.png","pentera-platform","Pentera Platform","https:\u002F\u002Fpentera.io\u002Fpentera-platform\u002F","Runs automated, safe attacks in production to validate exploitable attack paths, prioritise proven risk and confirm fixes. Modules cover internal networks, the external attack surface and cloud.",{"vendor_slug":71,"vendor_name":72,"vendor_logo":73,"product_slug":74,"product_name":75,"url":76,"description":77},"attackiq","AttackIQ","\u002Fvendor-logos\u002Fattackiq.png","attackiq-flex","AttackIQ Flex","https:\u002F\u002Fwww.attackiq.com\u002Fproducts\u002Fflex\u002F","Agentless, on-demand testing of security controls without deploying the full platform.",{"slug":79,"name":80,"problem":81,"products":82},"software-supply-chain","Software supply chain security","Malicious and vulnerable open-source packages are caught before they ship.",[83,89,97],{"vendor_slug":84,"vendor_name":85,"vendor_logo":86,"product_slug":84,"product_name":85,"url":87,"description":88},"socket","Socket","\u002Fvendor-logos\u002Fsocket.png","https:\u002F\u002Fsocket.dev\u002F","Detects and blocks malicious and risky packages in npm, PyPI and other ecosystems.",{"vendor_slug":90,"vendor_name":91,"vendor_logo":92,"product_slug":93,"product_name":94,"url":95,"description":96},"snyk","Snyk","\u002Fvendor-logos\u002Fsnyk.png","snyk-open-source","Snyk Open Source","https:\u002F\u002Fsnyk.io\u002Fproduct\u002Fopen-source-security-management\u002F","Finds and fixes vulnerable open-source dependencies in code and pipelines.",{"vendor_slug":98,"vendor_name":99,"vendor_logo":100,"product_slug":101,"product_name":102,"url":103,"description":104},"jfrog","JFrog","\u002Fvendor-logos\u002Fjfrog.png","jfrog-curation","JFrog Curation","https:\u002F\u002Fjfrog.com\u002Fcuration\u002F","Blocks malicious and risky open-source packages before they enter your repositories.",[106],{"slug":107,"name":25,"logo_path":108,"roles":109},"github","\u002Fvendor-logos\u002Fgithub.png",[110],"reported_by",{"slug":112,"title":113,"body":114,"framework_refs":115,"framework_notes":126},"github-actions-introduces-cache-mode-to-mitigate-cache-poisoning-in-cicd-pipelines","GitHub Actions Introduces Cache-Mode to Mitigate Cache Poisoning in CI\u002FCD Pipelines","Cache poisoning attacks in CI\u002FCD pipelines allow adversaries to inject malicious artifacts into shared build caches, which are then unknowingly consumed by subsequent workflow jobs — as seen in the Ultralytics PyPI and TanStack npm supply chain compromises. The root issue stems from insufficient access controls and configuration defaults that permit untrusted workflows to write to shared caches, creating a vector for software supply chain attacks. GitHub's new 'cache-mode' setting is a critical configuration hardening measure, but its value is only realized when developers actively adopt and configure it correctly. This incident highlights how CI\u002FCD infrastructure, often treated as a development convenience rather than a security boundary, is an increasingly attractive target for threat actors seeking to poison software at the build stage.",[116,117,118,119,120,121,122,123,124,125],"CIS Control 2: Inventory and Control of Software Assets","CIS Control 4: Secure Configuration of Enterprise Assets and Software","CIS Control 16: Application Software Security","NIST SP 800-218 (SSDF) PW.4: Reuse Existing, Well-Secured Software","NIST SP 800-218 (SSDF) RV.1: Identify and Confirm Vulnerabilities","NIST SP 800-161r1: Supply Chain Risk Management","NIST CSF DE.CM-3: Personnel Activity Monitoring","SLSA Supply Chain Levels for Software Artifacts (L2\u002FL3 Build Integrity)","OpenSSF Scorecard: Token-Permissions and Pinned-Dependencies checks","ITIL Change Management: Controlled pipeline configuration change processes",{}]