Fake CDN / SRI integrity-hash pin-rotation lure — "rotate your subresource integrity (SRI) sha384 / sha512 pin to the new safe payload" / "apply the new integrity attribute hash within 24 hours or your CSP will reject the cdn.example asset." Sender NOT on the CDN-canonical allowlist (jsdelivr.net, unpkg.com, cdnjs.com, cdnjs.cloudflare.com, cloudflare.com, fastly.com, akamai.com, akamaihd.net, amazonaws.com, cloudfront.net, azureedge.net, bunny.net, keycdn.com, stackpath.com, github.com, githubusercontent.com, githubapp.com). Real CDN providers ship integrity hashes via the CDN dashboard or package-publish flow, never via inbound email demanding a hash rotation on a deadline. Distinct from R7 npm-provenance-spoof (publish-trust) and R8 deploy-key (org repo trust) — this signal is specifically the *existing-script-tag* SRI-hash mutation pretext, a supply-chain script-injection precursor (drive-by code execution on every site that loads the CDN-hosted asset). Source: Red-Team R8 multi-agent council S1 (supply-chain specialist).

Fake CDN / SRI integrity-hash pin-rotation lure targeting repo maintainers, DevOps, and front-end engineers who routinely receive integrity-hash rotation requests citing real CVE narratives. The phish narrative arrives as: "Per the recent CDN advisory CVE-2026-XXXX, rotate your subresource integrity (SRI) sha384 pin on the script tag for the new safe payload. Update the integrity= attribute on the script tag within 48 hours or your CSP will block the cdn.example asset. Action required," or "A new sha384 / sha512 subresource integrity pin must be applied on your jsdelivr / unpkg <script> tag. Replace the existing integrity attribute hash with the new pin provided in this email within 24 hours, or your CSP will reject the script asset. Mandatory." The new pin = attacker payload — once the maintainer rotates the SRI hash on the script tag in production, every site that loads the CDN-hosted asset begins executing the attacker's code (drive-by code execution at supply-chain blast radius). Real CDN providers (jsDelivr, unpkg, cdnjs, Cloudflare, Fastly, Akamai) ship integrity hashes via the CDN dashboard or package-publish flow tied to the verified npm / GitHub publish event, never via inbound email demanding a hash rotation on a deadline. Sender NOT on the CDN-canonical allowlist (jsdelivr.net, unpkg.com, cdnjs.com, cdnjs.cloudflare.com, cloudflare.com, fastly.com, akamai.com, akamaihd.net, amazonaws.com, cloudfront.net, azureedge.net, bunny.net, keycdn.com, stackpath.com, github.com, githubusercontent.com, githubapp.com). Distinct from R7 npm-provenance-spoof (publish-trust spoof) and R8 deploy-key-rotation-lure (org repo trust takeover) — this signal is specifically the *existing-script-tag* SRI-hash mutation pretext targeting a script tag that already exists in the maintainer's production HTML. Fires when body references subresource integrity / SRI / integrity (hash/attribute/pin) / integrity= / sha (256/384/512) / SRI (pin/hash/rotation) / script tag (integrity) AND rotate (the integrity pin/hash/SRI) / update (the integrity pin/hash/SRI/attribute) / replace (the integrity pin/hash/SRI) / new (integrity pin/hash/SRI) / apply (the new pin/hash/integrity) AND CDN / jsdelivr / unpkg / cdnjs / cloudflare / fastly / akamai / cloudfront / cdn.example / asset / <script / script tag / CSP / content security policy AND within N hours-days / 24 hours / 48 hours / action required / mandatory / reject(ed) / block(ed) / CVE-YYYY urgency. Excludes the canonical CDN domains. Auto-classified as danger via the `-lure` suffix. Source: Red-Team R8 multi-agent council S1 (supply-chain specialist).