What is an SBOM (and Why Can’t You Ship Without One)?

In Omdia’s 2026 software supply chain security report, 73% of organizations that generate SBOMs say they enable more efficient vulnerability mitigation, yet 86% still find the generation process challenging. That gap between recognized value and operational difficulty is where most teams are stuck. For teams building and securing containerized applications, understanding what an SBOM is, and how to make it useful, is no longer optional.

This guide covers what SBOMs contain, why they matter for software supply chain security, how standard formats and tooling work, and where the industry is headed with regulations and enforcement.

Key takeaways

• An SBOM is a machine-readable inventory of every component inside a software artifact.
• SBOMs gain real value when paired with provenance attestations and cryptographic signatures.
• Generating SBOMs at image build time captures the full dependency tree, including OS packages.
• Regulatory mandates (EO 14028, CISA guidance, EU CRA) are making SBOMs a procurement baseline.

What is an SBOM?

Every software artifact ships with dependencies. A container image based on Alpine Linux might include dozens of system packages, each with its own version, license, and upstream maintainer. An application layer on top adds frameworks, libraries, and transitive dependencies that the developer may never have explicitly chosen. The deeper the stack, the harder it becomes to answer a basic question: what is actually running in production?

A software bill of materials answers that question. It’s a structured, machine-readable inventory of every component, library, and module inside a software artifact. Where a package manifest like package.json or requirements.txt lists declared dependencies, an SBOM captures the resolved dependency tree after the build, including transitive dependencies, system-level packages, and metadata about each component’s origin, version, and license. Think of it as a nutrition label for software.

What an SBOM contains

A well-formed SBOM includes several categories of metadata for each component:

• Component identity: Package name, version, and supplier (e.g., openssl 3.1.4, maintained by the OpenSSL Project)
• Licensing: The license type governing redistribution and use (MIT, Apache 2.0, GPL)
• Dependency relationships: How components depend on each other, including direct and transitive dependencies
• Unique identifiers: Package URLs (purl) or SWID tags that enable cross-referencing against vulnerability databases
• Checksums and digests: Cryptographic hashes that let consumers verify the component has not been tampered with
  This data is structured using open standards, primarily SPDX or CycloneDX, to keep it machine-readable and interoperable across tools, registries, and compliance workflows. In practice, an SPDX SBOM entry for a single package looks like this:

{
  "name": "openssl",
  "SPDXID": "SPDXRef-Package-openssl",
  "versionInfo": "3.1.4",
  "supplier": "Organization: OpenSSL Project",
  "licenseDeclared": "Apache-2.0",
  "checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}

A real SBOM contains one entry like this for every component in the artifact, from the base image’s OS packages up through the application’s runtime dependencies.

Why SBOMs matter for software supply chain security

The value of an SBOM becomes clear the moment something goes wrong. When the Log4Shell vulnerability was disclosed in December 2021, organizations with current SBOMs could query their inventories and identify every affected image within minutes. Teams without them spent days manually tracing dependencies across registries and deployment manifests.

Sonatype’s research found that nearly 65% of open source CVEs lack an NVD-assigned CVSS score, and when scored independently, 46% turned out to be high or critical. Without an SBOM, those unscored vulnerabilities are invisible.

Faster incident response

When a new CVE drops, the first question is always where are we exposed? An SBOM makes that question answerable in seconds rather than days. Cross-reference the affected package and version against your SBOM library, and you have an immediate blast radius. Pair the SBOM with continuous vulnerability scanning and the process becomes automated: new CVEs are matched against existing SBOMs, and affected images are flagged without manual intervention.

Customer spotlight: JWP, a video streaming platform serving more than 1 billion users, enabled vulnerability scanning across 400+ repositories in under an hour. With SBOMs feeding their scanning pipeline, the team fixed thousands of vulnerabilities while filtering out tens of thousands of non-critical issues, reducing noise and accelerating remediation.

Regulatory compliance

SBOMs are moving from best practice to legal requirements. In the United States, Executive Order 14028 helped set SBOM requirements in motion for software sold to federal agencies. CISA’s 2025 Minimum Elements guidance aims to clarify what a useful SBOM should include. The EU’s Cyber Resilience Act (EU CRA) extends similar requirements to products sold in the European market. For organizations operating in regulated industries, finance, healthcare, defense, and critical infrastructure, SBOM delivery is becoming a procurement gate.

Proactive verification, not reactive trust

SBOMs shift the security model from assuming software is safe to verifying that it is. Rather than trusting that a base image is clean because the registry says so, teams can inspect the SBOM to confirm which packages are present, which versions are running, and whether any known vulnerabilities apply.

In practice, that means writing policies against SBOM data: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation. These checks can run automatically in CI, turning the SBOM from a passive document into an active gate.

When combined with provenance attestations and cryptographic signatures, the SBOM becomes one layer in a verifiable chain of custody from source to deployment. You’re no longer taking the registry’s word for it. You’re cryptographically verifying it.

SBOM formats and standards

For an SBOM to be useful across teams, tools, and organizations, it needs a shared language. Two open standards dominate the landscape, each designed for a different primary use case.

SPDX (Software Package Data Exchange)

Developed by the Linux Foundation (ISO/IEC 5962:2021), SPDX is the most widely adopted format for license compliance and open source auditing. It is also the format used by BuildKit’s built-in SBOM generator, which attaches an SPDX document as an attestation to the container image during the build.

CycloneDX

Developed by the OWASP Foundation, CycloneDX is optimized for security workflows and DevSecOps pipelines. It includes fields for vulnerability metadata and dependency graphs, and integrates well with tools like OWASP Dependency-Track.

SBOM Formats at a Glance

	SPDX	CycloneDX
Primary focus	License compliance, open source auditing	Security, vulnerability management
Governed by	Linux Foundation (ISO/IEC 5962:2021)	OWASP Foundation
Format types	JSON, YAML, tag-value, RDF/XML	JSON, XML, Protocol Buffers
Best for	Compliance, due diligence, audits	DevSecOps pipelines, CI/CD integration
Container ecosystem support	Native in BuildKit attestations	Also produced by tools like Syft and Trivy

If you’re building container images, start with SPDX. It’s the format BuildKit generates natively, so you get an SBOM as a build output with zero additional tooling. Your downstream scanning tools may prefer CycloneDX, and that’s fine. The two formats are interoperable, and converters exist for moving between them. Let the build produce SPDX; let consumption tools handle conversion if they need it.

SWID (Software Identification Tags), a third format governed by ISO/IEC 19770-2, is primarily used for IT asset management in enterprise and government procurement. But it has largely lost traction in cloud-native and container workflows.

How SBOMs fit into container workflows

In traditional software development, SBOMs are often generated after the fact, bolted on as a compliance artifact during release. Container workflows offer a better approach: generating the SBOM at build time, as a native output of the image build process.

Build-time generation

When you build a container image with BuildKit, the builder scans the final image filesystem and produces an SBOM that reflects what actually shipped, not just what was declared in the Dockerfile. Because it captures the resolved state after all build stages complete, it includes OS-level packages, application-level dependencies, and any files copied from external sources.

Source-level SBOMs, generated from manifest files before the build, frequently miss transitive dependencies and system packages. An image-layer SBOM reflects reality.

Attestation and provenance

An SBOM tells you what’s in an image. Provenance attestations tell you how it was built: which builder, which source commit, which build platform. Together, they form a verifiable chain of evidence that auditors and policy engines can evaluate programmatically. This is the model described by SLSA (Supply-chain Levels for Software Artifacts), where Build Level 3 requires hardened build platforms with non-falsifiable provenance. SLSA is the specification; in-toto is the attestation format it uses.

The SBOM itself is attached to the image as an in-toto attestation using the SPDX predicate format. Provenance is attached the same way, so both travel with the image as verifiable, machine-readable metadata.

Registry storage

Once the image and its attestations are built, they need to live somewhere consumers can access them. Pushing the image to an OCI-compliant registry keeps the SBOM co-located with the artifact it describes. This matters because an SBOM that lives in a separate system, a shared drive, a compliance portal, or a CI artifact bucket, will eventually drift out of sync with the image it was generated from. Co-location eliminates that gap: pull the image, and you pull its SBOM and provenance with it.

Continuous scanning

With SBOMs attached to images and stored in a registry, they become inputs for continuous vulnerability monitoring. New CVEs are matched against the components listed in the SBOM without re-analyzing the image itself. Instead of re-scanning every image when a new vulnerability is disclosed, the scanner cross-references the SBOM inventory and flags affected images immediately.

Policy enforcement

Scanning identifies risk. Enforcement acts on it. Policy engines can consume SBOM data to gate deployments based on rules the team defines: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation.

These checks run automatically in CI, turning the SBOM from a passive document into an active gate. You’re no longer relying on manual review to catch a problematic dependency. The pipeline catches it before the image reaches production.

SBOM maturity: Where does your organization stand?

SBOM adoption isn’t binary. Most organizations fall somewhere on a spectrum from ad hoc to fully scaled. The following maturity model helps teams assess where they are and what to prioritize next.

Level	Generation	Storage	Scanning	Governance
Ad hoc	Manual, on request	Local files or shared drives	Occasional, tool-dependent	No formal policy
Pilot	Automated for 1–2 apps or services	Alongside build artifacts	Integrated into CI for pilot apps	Basic policy drafted
Production	Automated for all new images	Attached to images in OCI registries	Continuous, with alerting	Policies enforced in pipelines
Scaled	All images, including third-party ingestion	Centralized SBOM management platform	Continuous with policy gating	Cross-org governance, audit trails, supplier requirements

Omdia’s 2026 software supply chain security survey surfaced that more than half of the organizations generating SBOMs are only generating them on a case-by-case basis. 

Common misconceptions about SBOMs

SBOMs are just a compliance checkbox

Teams that generate SBOMs solely to satisfy a procurement requirement are missing the operational value. SBOMs are most useful as a live data source for vulnerability management, incident response, and dependency tracking. A one-time SBOM generated for an audit and then filed away provides a false sense of coverage.

They’re the same as SCA

Software composition analysis (SCA) tools scan code or images for known vulnerabilities. An SBOM is the inventory that makes that scanning possible. SCA and SBOMs generally work together. The SBOM is the inventory, and SCA tools use that inventory, often generating their own, to check for known vulnerabilities. The distinction matters because scanning tends to be only as good as the inventory behind it.

SBOMs are a one-time artifact

An SBOM is tied to a specific image digest. Every time you rebuild an image, the SBOM should be regenerated to reflect any dependency changes. Stale SBOMs create a gap between what you think is running and what’s actually deployed. Automated build-time generation eliminates this drift.

SBOMs substitute runtime security

SBOMs tell you what shipped. They do not tell you what’s happening at runtime. An SBOM will not catch a zero-day that hasn’t been disclosed yet, detect anomalous process behavior inside a running container, or verify that the application logic is correct. SBOMs are one layer in a defense-in-depth model: they handle inventory and composition. Runtime monitoring, network policies, and access controls handle the rest.

What can go wrong without SBOMs

Let’s say a zero-day vulnerability is disclosed in a widely used library. Without SBOMs, the security team starts a manual triage: checking Dockerfiles, querying registries, asking developers which versions they use. Hours pass. Some images are missed because the affected package is a transitive dependency three levels deep. By the time the blast radius is mapped, the vulnerability has been public for two days.

With SBOMs attached to every image, the same triage takes minutes. Query the SBOM database for the affected package and version, get a list of every image that includes it, and prioritize remediation based on deployment context.

Getting started with SBOMs

The most common mistake teams make is treating SBOM adoption as a large-scale transformation project that’ll derail workflows. It doesn’t need to be.

• Start with one image. Pick a production image and enable SBOM generation on the next build. With BuildKit, that is a single flag:

docker buildx build –attest type=sbom –tag myapp:latest .

Review the output. This single step often reveals transitive dependencies and OS packages you did not know were in the image.

• Automate generation in CI. Extend the flag to your CI pipeline so every image build produces an SBOM automatically.
• Store SBOMs alongside images. Attach SBOMs as attestations in your OCI registry so the SBOM stays co-located with the artifact it describes.
• Connect to monitoring. Feed SBOMs into a vulnerability monitoring tool that can continuously match components against new CVEs. This closes the loop between inventory and action.
• Set policies. Define what is acceptable: maximum CVE age, required minimum SBOM completeness, blocked licenses. Enforce these policies in the pipeline so non-compliant images are flagged before deployment.

Build with visibility, ship with confidence

SBOMs are the foundation of software supply chain security. They turn opaque software artifacts into transparent, auditable inventories that security teams, compliance officers, and developers can all use. But an SBOM alone is not enough. The real value comes when SBOMs are generated at build time, paired with provenance attestations, and continuously monitored against emerging threats.

Docker makes this workflow native. Docker Hardened Images ship with complete SBOMs, SLSA Build Level 3 provenance, OpenVEX exploitability data, and cryptographic signatures on every image. Meanwhile, Docker Scout provides continuous vulnerability monitoring powered by the SBOM data attached to your images, surfacing actionable insights across your entire image portfolio. Together, they give teams a verifiable chain of custody from source to production, with no manual assembly required.

Frequently asked questions

What does SBOM stand for?

SBOM stands for software bill of materials. It’s a structured inventory of every component, dependency, and metadata element inside a software artifact, formatted in a machine-readable standard like SPDX or CycloneDX.

Are SBOMs required by law?

In the United States, Executive Order 14028 requires SBOMs for software sold to federal agencies. CISA’s 2025 draft guidance proposes an updated set of minimum elements. The EU Cyber Resilience Act extends similar requirements to products sold in the European market. For organizations in regulated industries, SBOMs are increasingly a procurement prerequisite rather than a voluntary practice.

What is the difference between an SBOM and a package manifest?

A package manifest (package.json, requirements.txt, go.mod) lists the dependencies a developer declared. An SBOM captures the fully resolved dependency tree after the build, including transitive dependencies, system-level packages, and metadata like licenses and checksums. The manifest is an input to the build; the SBOM is an output that reflects what was actually shipped.

How often should an SBOM be updated?

An SBOM should be regenerated every time the associated artifact is rebuilt. For container images, this means generating a new SBOM with each image build. Between rebuilds, the existing SBOM remains valid for the specific image digest it describes, but new CVEs may be discovered against the components it lists. Continuous monitoring against the stored SBOM catches these without requiring a rebuild.

Source

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.

from Docker https://ift.tt/KnAxqIL
via IFTTT

Fake AI Agent Skill Passed Security Scans and Reportedly Reached 26,000 Agents

Security firm AIR built a fake AI agent skill, pushed it through a popular skill marketplace and an Instagram ad, and says it reached roughly 26,000 agents, including some on corporate accounts.

Every skill security scanner the firm tested it against marked it safe. The payload was harmless by design: it collected the user's email address and did nothing else.

The point was to show that none of the signals people lean on to trust a skill caught it: not the scanners, not the GitHub stars, not the open-source reputation.

A skill is a bundle of instructions an agent loads into its own context and follows with roughly the authority of a user prompt. That trust is the whole problem, and it is the reason skill-scanning tools exist in the first place.

The skill, named brand-landingpage, claimed to build a landing page using Google's Stitch design tool, aimed squarely at non-technical users.

To make it look credible, AIR went after two trust signals: GitHub stars and a clean scanner verdict. For the stars, it opened a pull request to a skill marketplace repository with around 36,000 stars and 156 skills.

The pull request was merged after a few days, so the skill inherited the repo's count. Then it ran an Instagram ad aimed at marketers, salespeople, and designers, who installed it and put it to work.

Why the scanners missed it

The scanners AIR tested analyze the package you hand them: the SKILL.md and the files shipped with it. That's Cisco's, NVIDIA's, and the ones wired into skills.sh.

AIR's skill carried no setup instructions of its own. It told the agent to install the "Stitch SDK" by following the documentation at an external link, stitch-design.ai, a domain AIR controls, not Google (the real Stitch lives at stitch.withgoogle.com).

At first, the link led to the genuine Stitch docs, so the scanners, seeing a clean package that pointed at a plausible setup page, cleared it. The page the agent would actually fetch and follow sat outside the scan.

Once the skill was installed widely, AIR swapped the page behind that link. The new version told the agent to download and run a script.

In the demo, it only mailed the user's address back to AIR, which is how the firm counted the agents it reached. A real operator could have used that foothold to read files, move data, or hit internal systems, bounded only by what the agent could reach.

AIR is not the first to show this. Three weeks earlier, Trail of Bits bypassed ClawHub's malicious-skill detector, Cisco's scanner, and all three scanners wired into skills.sh. Its conclusion was blunt: a scanner checks a fixed package, while an attacker can keep tweaking the payload until it passes.

Real campaigns have used the same trick for months, keeping the submitted skill clean and hosting the payload on a site the agent only fetches at install.

The problem is structural: the scan happens once, but the page a skill points the agent to can be rewritten at any time after. Anthropic's own docs already warn that skills fetching external URLs are risky for exactly this reason, since the content can change after the skill is vetted.

Separate research this year found scanners often disagree, because each one judges a skill in isolation, blind to its external links and to what changes after review.

What to do

The read for defenders is the same one researchers keep landing on, now with a sharper example behind it. Treat skills as software, not text. Vet what a skill points to, not just what ships inside it.

Most of these add-ons got installed with no review, so the first job is finding what is already running. Route new skills through a single source you control, and re-check them when anything changes, because a clean result at install does not stay clean if the skill phones out to a link someone else can edit.

Pin versions. Hold agents to the least privilege. Assume any external instruction an agent fetches runs with the agent's access.

The scale figures come from AIR alone, and they deserve a skeptical read. The firm is launching a managed skill marketplace and closes the write-up, pitching it, so the 26,000 number, the corporate-account detail, and the claim that it could have seized full control of every agent are the company's own and are not independently confirmed.

What holds up is the method. The named scanners really do judge only the submitted package, the external-link blind spot is real and has been independently demonstrated, and the trust signals AIR borrowed, stars, and a clean scan are exactly the ones the ecosystem still treats as proof.

The experiment does not expose a new bug so much as it lines up every weak trust signal around agent skills into one run: stars that can be borrowed, a scan that reads a snapshot, and a link that can be rewritten after the check clears.

Whether the real figure is 26,000 or a fraction of it, the gap it walks through is one that defenders still have not closed.

from The Hacker News https://ift.tt/mwvp0Jb
via IFTTT

Trump Order Sets 2030 Deadline for Federal Post-Quantum Crypto Migration

President Trump signed an executive order on June 22 setting hard deadlines for federal agencies to move high-value assets and high-impact systems to post-quantum cryptography.

Key establishment must move by December 31, 2030; digital signatures by December 31, 2031. EO 14409 leaves national security systems on a separate track.

The deadlines matter because of a threat that does not need a working quantum computer today. Adversaries can collect encrypted U.S. data now and decrypt it later, once a large-scale quantum machine exists, the risk is known as "harvest now, decrypt later".

The order describes that risk directly and pulls the government's PQC timeline forward by four to five years. The prior government-wide target, set by the 2022 National Security Memorandum 10, ran to 2035.

The two deadlines line up with the standards NIST finalized in August 2024. Key establishment uses FIPS 203, the ML-KEM algorithm formerly called CRYSTALS-Kyber.

Digital signatures use FIPS 204 and 205, ML-DSA, and SLH-DSA. The standards have been ready for almost two years. The order is what turns them into a schedule with consequences.

What agencies have to do, and when

The near-term clock starts fast. Within 30 days, each agency head names a PQC migration lead who reports to the agency CIO and owns the cryptographic inventory and migration plan.

Within 90 days, OMB issues guidance requiring agencies to review their inventories of high-value assets and high-impact systems, plan the migration, and submit that plan.

NIST runs a pilot migration on a subset of its own systems, to be finished by December 31, 2027.

The order reaches past federal networks. The Federal Acquisition Regulatory Council has 180 days to propose a rule giving "covered contractors" until December 31, 2030, to meet NIST's FIPS, including the PQC algorithms.

A second proposed rule, due in 270 days, would fold cryptographic flaws into contractor vulnerability disclosure programs, including tests for missing encryption and for non-FIPS algorithms. Sector Risk Management Agencies and CISA are told to help critical infrastructure operators build their own migration plans, though that part is assistance, not a mandate.

Then there is the inventory angle. Within 270 days, CISA and NIST are to publish the minimum elements for a cryptographic bill of materials, a machine-readable list of the cryptographic assets in a piece of hardware or software.

That is the groundwork for crypto-agility: you cannot swap out weak algorithms on a deadline if you do not know where they are.

The practical read

For federal teams and the vendors who sell to them, the work is the inventory, and it starts now. Find every place key exchange and signatures happen, flag what is not NIST PQC, and sequence the swap against the 2030 and 2031 dates.

Contractors should expect the FAR clause and a 2030 compliance line once the rule lands. The standards exist. The deadlines now exist. The gating task for almost everyone is knowing what cryptography is running, and where.

A companion order signed the same day, "Ushering in the Next Frontier of Quantum Innovation," pushes the other side of the equation: building the quantum computers that make the migration urgent in the first place.

The teeth are still being written. OMB's 90-day guidance and the FAR rules will decide whether 2030 and 2031 become real procurement pressure or just another federal migration target that slips once the hard work starts.

from The Hacker News https://ift.tt/EAhypzJ
via IFTTT

OpenAI Expands Daybreak With GPT-5.5-Cyber to Help Defenders Patch Security Flaws

OpenAI on Monday said it's releasing an improved version of its GPT‑5.5‑Cyber model to trusted defenders as part of the Daybreak initiative, the artificial intelligence (AI) company announced last month.

Calling GPT‑5.5‑Cyber its "strongest model yet for finding and helping patch software vulnerabilities," OpenAI said the model can "sustain deeper analysis across large codebases" to identify security issues, validate them in a controlled environment, and develop and test patches.

In tandem, the tech upstart is releasing an update to the Codex Security plugin⁠ to speed up the process of discovering and patching vulnerabilities in existing systems, alongside preventing new vulnerabilities from entering production codebases.

"Developers can run deep scans or review recent changes, generate reports with severity, affected code locations, validation evidence, and remediation guidance, trace attack paths, build threat models, validate findings, and generate codebase-specific patches for review," OpenAI said.

On top of that, the plugin⁠ can triage and validate existing findings from scanners, advisories, bug-bounty reports, or ticketing systems, and then facilitate patch generation at scale to quickly close a backlog of vulnerabilities.

OpenAI is also launching a new initiative called Patch the Planet in partnership with Trail of Bits to help secure open-source projects. Initial participants include cURL, NATS Server, pyca/cryptography, Sigstore, aiohttp, the Go project, freenginx, Python, and python.org. 

These moves come as frontier models from Anthropic and OpenAI are accelerating vulnerability discovery, leaving software maintainers overwhelmed with an ever-increasing volume of bugs that need to be verified, triaged, and patched. While previously the challenge lay in finding vulnerabilities, the bottleneck has now shifted to patching them.

AI models come with capabilities to navigate large codebases, reason through attack paths, and flag security issues that might have otherwise stayed hidden. Case in point is a 29-year-old flaw in the Squid web proxy (CVE-2026-47729, aka Squidbleed) that can leak cleartext HTTP requests belonging to other users under certain conditions.

Cyber experts have also raised concerns that more advanced AI models are turbocharging bad actors' abilities to take advantage of security vulnerabilities, forcing the industry to plug the holes almost as soon as they are discovered.

"Threat actors with limited technical expertise can use publicly available AI models for malicious purposes," the Canadian Centre for Cyber Security said in guidance released in May 2026. "Organizations should assume that AI-driven exploitation may bypass preventative controls, significantly outpace vendors' capacity to publish corrective measures and challenge the organization's ability to deploy."

Patch the Planet aims to reduce this undue burden placed on maintainers by letting security engineers review and validate findings, work with projects to develop patches and tests, and help build reusable vulnerability discovery workflows with the goal of improving security even after the initial fixes are released.

"With Patch the Planet, we are working with researchers, maintainers, enterprises, and partners to make powerful cyber capability available to defenders with appropriate access, governance, and human oversight," OpenAI said.

The AI company also said the Daybreak initiative has already helped surface a number of vulnerabilities across various operating systems and web browsers -

• 8 kernel pointer information leak proofs-of-concept (PoCs) and 24 local privilege escalation exploits in the Linux Kernel
• A 23-year-old use-after-free⁠ in OpenBSD's kernel implementation of System V semaphores
• 34 vulnerabilities and 7 local privilege escalation PoCs in FreeBSD
• 6 vulnerabilities in dnsmasq (CVE-2026-4890⁠, CVE-2026-4891⁠, CVE-2026-4892⁠, and CVE-2026-5172⁠)
• A denial-of-service (DoS) technique called HTTP/2 Bomb impacting major HTTP/2 implementations, including NGINX, Apache, IIS, and Pingora
• 5 exploitable vulnerabilities in Google Chrome's V8 JavaScript engine
• 10 exploitable Apple Safari vulnerabilities
• A WebAssembly vulnerability (CVE-2026-8390⁠) in Mozilla Firefox

"Patch the Planet is designed to put that full defensive loop in service of maintainers: discovery, validation, severity review, disclosure, patch development, testing, and deployment," OpenAI said. "Frontier models can make parts of that loop faster, but the aim is to give the people responsible for shared infrastructure better tools and more capacity, while preserving their agency over how changes land."

The developments go hand in hand with bad actors misusing AI to compress the time between finding and exploiting a weakness, shrinking the window defenders have to respond. The use of vibe-coded exploits also heralds a new chapter where the technology is not only lowering the barrier to exploit development, but also enabling attackers to cast a wide net across newly disclosed vulnerabilities with lesser effort.

Intelligence agencies from Australia, Canada, New Zealand, the U.K., and the U.S. have warned that advanced AI models can speed up the speed, scale, and sophistication of cyber threats, while lowering the barrier for malicious actors and shrinking the window between vulnerability discovery and exploitation ever more quickly.

"Frontier Al models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months, the agencies noted. "In this environment, cyber resilience is integral to advancing business continuity, market confidence, and long-term value."

"Success will come from getting the basics right, acting quickly, and integrating cyber security into core business strategy. Those that do not will face growing operational and strategic disadvantage."

from The Hacker News https://ift.tt/iGnVmoO
via IFTTT

The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration

Executive Summary

We recently identified a bucket hijacking technique impacting multiple services across major cloud service providers (CSPs). The attack technique exploits a fundamental architectural flaw that is common across cloud providers and could potentially affect other cloud providers as well.

Our research reveals that an attacker can silently compromise an organization's active data streams by rerouting data into an external storage bucket. Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk. This bucket hijacking reroutes critical logs and sensitive data directly to the attacker’s environment.

We have shared these findings with Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.

We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Key Architectural Elements Enabling the Attack

Before detailing the attack methodology, it’s important to understand several architectural elements that, when combined, make bucket hijacking possible.

Data Stream Overview

A data stream is an automated, continuous pipeline designed for high-volume data movement between services. Once configured, these streams operate autonomously in the background to push telemetry, audit logs or objects from a source environment to a designated storage destination for processing and long-term retention.

Major CSPs facilitate automated data streams. These streams serve as critical nodes for routing, processing and backing up data within an organization's infrastructure, such as:

• A cloud logging sink in Google Cloud acts as a router for log entries, directing them to a chosen destination. While primarily used to route and store logs in centralized log buckets for purposes like analysis and retention, a sink can also export logs to a Google Cloud Storage (GCS) bucket.
• Bucket replication in AWS is a feature that automatically duplicates data from a source S3 bucket to a designated destination S3 bucket.

Global Uniqueness of Bucket Names

Cloud environments often stream data into buckets such as an S3 bucket in AWS or a GCS bucket in Google Cloud. Because bucket names are typically unique across the entire cloud provider, no two users can have the same bucket name. This design simplifies data stream establishment by providing a single, predictable target. However, it also creates a shared namespace where a destination's identity is tied solely to its name, rather than to a specific, immutable account owner. This characteristic is the foundational logic behind our discovery.

Permissions to Modify Data Stream Destinations

The data stream is frequently defined by a routing resource that is configured with a specific destination. To legitimately modify this destination, the user must possess specific, granular identity and access management (IAM) update permissions for that resource.

For example, modifying the destination for a cloud logging sink requires the logging.sinks.update permission. This routes logs to a bucket. Our research found that certain permissions outside of this traditional update purview could be leveraged to reroute data streams.

The Bucket Hijacking Attack

We now turn to discussing the attack flow before any mitigations were provided by the affected CSPs. After compromising a cloud environment and securing the permissions required to delete a target bucket, an attacker was effectively positioned to intercept and redirect a cloud data stream. By deleting the original bucket and immediately recreating a new bucket with the same name within their own account, the attacker could have redirected the data stream. This could have led to the exfiltration of the target's data to the attacker's account.

Figure 1 shows the attack flow diagram.

Figure 1. The bucket hijacking attack flow.

Simulating Bucket Hijacking in Google Cloud Logging

We simulated the bucket hijacking technique in Google Cloud Logging. In the simulation, we used a sink that routes logs to a cloud storage resource, as shown in Figure 2.

Figure 2. An existing sink referencing a GCS bucket.

After routing the logs, the original cloud storage bucket was deleted, as Figure 3 shows.

Figure 3. Deleting the targeted bucket used by the sink.

We then created a new bucket with the same name in an attacker-controlled environment, as shown in Figure 4.

Figure 4. Recreating the bucket in an external project.

Subsequently, logs were routed to this external cloud storage bucket, allowing the attacker to obtain extensive information about the compromised environment, as shown in Figure 5. The required permissions the attacker needed to have are storage.objects.delete (to empty the bucket) and storage.bucket.delete (to delete the bucket).

Figure 5. Logs written into the attacker’s controller bucket.

The Expansion to Multiple Services Within Google Cloud

Data streaming into a GCS bucket is not unique to cloud logging. There are many other Google Cloud services in which data can be streamed into cloud storage. We identified and tested a representative subset of potentially vulnerable services, specifically Pub/Sub and Storage Transfer Service, to confirm the systemic prevalence of this security risk.

Pub/Sub

Pub/Sub is an asynchronous messaging service that decouples upstream event producers from downstream processing services. It allows applications to broadcast messages to a topic, which are then distributed to one or more subscriptions for consumption by downstream systems.

This architecture enables scalable, event-driven communication. This allows disparate components such as log aggregators, data pipelines and real-time analytics engines to exchange information reliably without needing direct, synchronous connections.

The Pub/Sub architecture has three core components:

1. Publishers (producers) send messages to a named logical channel called a topic, without needing to know who or what will receive them.
2. Topics act as a buffer or distribution hub, holding the messages until they can be delivered.
3. Subscribers (consumers) listen to specific topics via a subscription. When a message arrives in the topic, the Pub/Sub service pushes it to the subscribers (push model) or the subscribers actively request it (pull model).

To simulate a bucket hijacking attack on Pub/Sub, we took the following steps:

1. We created a new Pub/Sub topic and a subscription linked to a GCS bucket
2. We configured the GCS bucket with the necessary permissions to grant access to the service agent:
   1. Storage object creator (roles/storage.objectCreator)
   2. Storage legacy bucket reader (roles/storage.legacyBucketReader)
3. We published a message to the topic, which was successfully delivered to the initial bucket
4. We deleted the original bucket and created a new bucket with the same name in a different project (the attacker's project)
5. When a message was published manually again, we found that the service exfiltrated the message to the attacker's environment

The successful redirection of the message stream proved that the bucket hijacking attack technique was directly applicable to the Pub/Sub service, allowing an attacker to exfiltrate data by deleting and recreating the destination bucket.

Storage Transfer Service

Storage Transfer Service is a managed data migration tool designed to automate the movement of large volumes of data into, out of or between cloud storage environments. It allows organizations to schedule and manage massive data transfers from external sources (like AWS S3 or on-premises systems) to GCS buckets, or to synchronize data between different cloud storage projects.

The service handles the underlying infrastructure, retries and checksum validation. It provides a way to populate data lakes or perform large-scale disaster recovery backups.

The Storage Transfer Service architecture operates as a centralized orchestration engine that manages the movement of data between a designated source and sink. When a user defines a transfer job, they specify the source, the destination and the scheduling parameters. The source can be an S3 bucket, a URL list or another GCS bucket.

To simulate a bucket hijacking attack on Storage Transfer Service, we took the following steps:

1. We configured a new transfer job with a GCS bucket as the source and another GCS bucket as the destination
2. We assigned the necessary permissions to the buckets to grant access to the service agent:
   1. Source bucket: Storage Object Viewer (roles/storage.objectViewer) and Storage Legacy Bucket Reader (roles/storage.legacyBucketReader)
   2. Destination bucket: Storage Object Admin (roles/storage.objectAdmin)
3. The user then initiated the transfer job
4. We deleted the destination bucket and then immediately re-created it in a different project (the attacker's environment)
5. We wrote a new object into the source bucket
6. After a period determined by the job's scheduling parameter, the object appeared in the newly hijacked destination bucket, which was under the attacker's control

The impact of this risk was significantly magnified by its broad applicability across numerous services. The permissions storage.buckets.delete and storage.objects.delete could be used to bypass the granular update permissions required for specific resources to redirect sensitive data streams such as logging.sinks.update, pubsub.subscriptions.update and storagetransfer.jobs.update.

The Expansion to Another Cloud Provider: AWS

The architectural flaw of global bucket name uniqueness is not exclusive to Google Cloud. AWS S3 buckets operate under the same design logic. Given this commonality, we investigated whether we could apply the same hijacking technique within the AWS ecosystem.

We successfully simulated the bucket hijacking attack using the S3 bucket replication feature. This feature enables the configuration of a source and destination bucket, where all objects written to the source bucket are automatically replicated to the destination bucket. The simulation followed these steps:

1. We created a bucket in our environment with a replication rule targeting a second bucket within the same account
2. We deleted the bucket and immediately recreated a new one using the same name within an external account
3. We uploaded a file to the source bucket
4. We observed the file appearing in the destination bucket located in the external account

Like in Google Cloud, we identified that this was not a localized issue, but applied to a number of AWS data stream services. We simulated the same technique using Amazon Data Firehose (where the destination is an S3 bucket) and observed the same behavior.

Cross-Subscription Data Exfiltration in Azure

Finally, we tested Azure’s environment for the same attack technique. Azure platform limitations prevent the immediate reuse of storage account names across different tenants for several days after deletion. However, we were able to simulate a cross-subscription attack technique.

This scenario was particularly relevant if an attacker gained permission to delete a storage account in one subscription and intended to reroute data to another. This allowed them to move data to a subscription where they maintained higher privileges and persistence, or perhaps where they previously lacked data access permissions. Ultimately, this technique relied on the fact that a storage account must be created with soft-delete disabled to ensure the name was released and could be promptly reclaimed.

We used Azure Monitor to demonstrate this attack. Diagnostic settings in Azure Monitor can be configured to export resource logs (e.g., metrics and audit events) to an Azure storage account. While the configuration stores the destination via its Azure Resource Manager (ARM) Resource ID, the internal pipeline resolves the storage account at runtime using its DNS name ({accountname}.blob.core.windows.net).

This architectural behavior facilitated the execution of the attack. If an attacker deleted a destination storage account and recreated it with an identical globally unique name in a different subscription within the same tenant, the diagnostic pipeline would continue to write logs to the attacker-controlled storage account.

The attack was less severe in Azure than in AWS or Google Cloud because it was limited to a cross-subscription scope rather than a cross-tenant one.

Exploitation Scenarios and Excessive Permissions Risks

The practical execution of bucket hijacking relies on specific exploitation vectors that are often facilitated by the widespread use of over-privileged administrative roles.

Exploitation Scenarios and Detection Challenges

We identified two distinct scenarios that could enable an attacker to execute a bucket hijacking operation:

1. Privilege escalation: As demonstrated in our simulations, a compromised identity with the permission to delete a bucket could misuse this access to redirect data streams to the attacker's own bucket. The widespread application of storage administrator roles significantly increased the risk of this attack technique and overcame the need for the more granular logging.sinks.update permission (as shown later).
2. Dangling router resources: In a similar exploit not demonstrated in this article, if someone deleted a bucket and failed to remove the associated router resource, an attacker could create a new bucket using the same name in their own environment. This action effectively redirects the data to the attacker's bucket, granting the attacker access to the victim's ongoing data.

Detecting these attack scenarios is particularly challenging. In scenarios where destination resources are used primarily for long-term retention or backup, the target may not detect the initial deletion of the original storage bucket. Because the data stream continues to operate autonomously, the sink configuration in Google Cloud appears valid upon inspection as shown in Figure 6. This allows the hijacking and subsequent data exfiltration to remain largely undetected.

Figure 6. The sink configuration remains intact and operational after recreating the bucket.

How Over-Privileged Roles Increase the Risk

Cloud providers frequently offer broad storage administration roles that grant wide-reaching deletion privileges by default, which significantly increases the practical risk of this attack technique.

For example, in Google Cloud the common storage admin role provides the storage.buckets.delete permission. However, as Figure 7 shows, it does not include granular permissions to modify data stream configurations like:

• logging.sinks.update
• pubsub.subscriptions.update
• storagetransfer.jobs.update

Figure 7. The predefined Google Cloud storage admin role includes bucket deletion permission (highlighted in red) but lacks granular update permissions for data stream resources.

Mitigation Strategies

Google has adjusted how router resources interact with target storage resources since the time of our initial research.

Microsoft recommended that Azure users review documentation and tooling on addressing dangling DNS for subdomain takeovers (see Additional Resources).

Users can also employ additional defense strategies.

Mitigating the bucket hijacking technique requires a two-pronged approach focusing on preventative guardrails and proactive monitoring. Prevention starts with the principle of least privilege. Organizations must strictly limit the IAM permissions for deletion actions, specifically:

• Storage.buckets.delete in Google Cloud
• DeleteBucket in AWS
• Microsoft.Storage/storageAccounts/delete in Azure

These permissions should be restricted to a minimal set of administrative roles and should never be assigned to service accounts or applications without rigorous justification.

In addition, the following mechanisms help to prevent the bucket hijacking technique:

• Organizations can prevent bucket hijacking for data exfiltration by enforcing data perimeter controls that restrict resource access to stay within a trusted organizational boundary.
  • In AWS, data perimeter policies — implemented through service control policies (SCPs) and virtual private cloud (VPC) endpoint policies — can ensure that workloads within the organization are unable to write data to S3 buckets that belong to external accounts. This can effectively block the exfiltration path even if an attacker substitutes a malicious bucket, though the approach has some limitations.
  • Similarly, in Google Cloud, VPC Service Controls define a security perimeter around projects and services, to block any API call attempting to access Cloud Storage buckets outside the perimeter.

Deploying these controls as a baseline ensures that data cannot leave the trusted environment boundary, neutralizing the core mechanism of this attack technique.

• AWS offers account regional namespaces for S3 buckets, which scope bucket names to the owning account and region rather than to a single global namespace. This directly eliminates the bucket hijacking vector. If a bucket is deleted, no other account can reclaim its name. This prevents attackers from intercepting traffic by re-registering abandoned bucket names.

For detection, organizations must implement robust monitoring solutions that specifically alert on the attempted deletion of a storage bucket. Security teams should prioritize high-severity alerts for storage deletion API calls, focusing specifically on resources that house sensitive information.

Given the high frequency of storage deletion events in large-scale environments, leveraging data security posture management (DSPM) capabilities is essential. It is particularly important to prioritize monitoring and to focus specifically on high-value, sensitive assets, as shown in a Cortex XSIAM alert in Figure 8.

Figure 8. Cortex XSIAM alert: Deletion of a high-sensitivity bucket detected.

Conclusion

The bucket hijacking technique detailed in this research exploits the global uniqueness of storage resource names in the major cloud providers. We have demonstrated how a configure-and-forget approach to data streams can lead to silent, long-term data exfiltration.

Reliance on a globally unique, static resource name for buckets is an architectural design common across cloud providers. As such, this technique could be portable to other cloud services and providers not covered in this research.

Our findings underscore two primary lessons for the security community:

• Architecture defines the security boundary: Fundamental design choices made by cloud providers directly influence the security boundaries of our environments. A robust mitigation strategy must include awareness of these architectural nuances and the implementation of guardrails.
• A cross-cloud exploitation methodology: While cloud providers are often managed as distinct ecosystems, their shared design philosophies allow identical attack techniques to be applied across providers. Our simulations prove that a specific architectural observation can evolve into a universal methodology for hijacking sensitive data streams. We encourage the security industry to adopt a cloud-agnostic mindset. A design flaw discovered in one provider could be a blueprint for exploiting another.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Cortex Cloud customers are better protected from the techniques discussed in this article with cloud runtime security operations through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Cortex has several out-of-the-box rules built into the Analytics module that detect data movement to external buckets. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified. When this occurs, they trigger alerts, which provide early warning and, in some cases, prevention operations to prevent further compromise from these attacks.
• Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses:
  • Cloud Infrastructure Entitlement Management (CIEM)
  • Identity Security Posture Management (ISPM)
  • Data Access Governance (DAG)
  • Identity Threat Detection and Response (ITDR)
• These tools provide the necessary capabilities to improve identity-related security requirements within cloud environments. This includes:
  • Accurately detecting misconfigurations
  • Identifying unwanted access to sensitive data
  • Conducting real-time analysis surrounding usage and access patterns

Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 000 800 050 45107
• South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

from Unit 42 https://ift.tt/JQFZNjU
via IFTTT

Guarding AI memory

1. What AI memory is (and why it matters)
2. What is an agent memory attack?
3. How Microsoft approaches memory security in Microsoft 365
4. A guiding framework for building safe AI memory
5. Key takeaways
6. Learn more

AI memory transforms an AI system from a stateless tool into a learning collaborator.  That unlocks powerful experiences, but it also increases the attack surface of the AI system. Without memory, attackers need to achieve their objective in a single prompt.  With AI memory, they can shape behavior gradually over time or plant memories that influence agent reasoning after the original context is gone and user awareness is lower.

Microsoft takes a defense-in-depth approach to protect AI memory spanning every layer of the stack: storage, retrieval, model interaction, and user control.

What AI memory is (and why it matters)

 AI systems use memory to retain and recall information across interactions. This information is then used to shape future behavior. This enables:

1. Personalization: Agents gain a deep understanding of the user’s preferences.  This provides continuity across interactions.
2. Agentic coherence: Agents build durable domain knowledge that strengthens performance. As AI systems evolve, this persistent state becomes central to both capability and correctness.

What is an agent memory attack?

AI memory serves two roles. It stores high-value user information and must be protected like customer data. It also shapes agent behavior and drives tool calls and must be governed with the same rigor as any system that can act. Memory governance is also challenging since memory events usually happen asynchronously from user interactions, changing traditional human in the loop patterns.

AI memory changes the threat model. Without memory, attackers need to “win” in a single prompt. Using AI memory, an attacker can stage an attack over time. Once compromised, memory can trigger behaviors outside of their original context. Since AI memory attacks happen outside of their original context, defenses are often lower and forensics are harder.

Building safe AI memory is one of the most consequential challenges in AI. It requires balancing personalization, capability, privacy, security, and governance.

Scenario: delayed tool execution through adversarial memory poisoning

The following is a hypothetical scenario illustrating this class of risk. While simplified for clarity, it reflects patterns observed in real-world research. Microsoft designs protections to detect and mitigate these patterns as they evolve:

A user opens a shared document. Its formatting contains hidden instructions embedded by an attacker intended for the AI assistant: a directive to exfiltrate the user’s schedule. The assistant processes the document but takes no immediate action.

Days later, in an unrelated conversation, that message triggers the dormant malicious instructions from the earlier session, causing the assistant to update its memory with attacker-defined content.  The attacker now gets all updates to the user’s schedule.

This is delayed tool invocation: the attack’s power lies in the temporal gap between exposure and execution.

How Microsoft approaches memory security in Microsoft 365

Memory Creation

Memories pass through sanitization checks on write. Proprietary Microsoft prompt-injection classifiers inspect content for malicious input and strip it before anything is written.  M365 Copilot is designed to run Task Adherence checks on every explicit memory write. Task Adherence identifies discrepancies such as misaligned tool invocations relative to user intent, mitigating prompt injection impact for the memory tool call.  Personalization using AI memory can be controlled with tenant level policy.

Memory Storage

Once stored, memories are governed by the data policies available across M365 like Data Subject Requests (DSR) and tenant isolation.  They follow the same security and compliance policies as other mailbox data, such as Customer Lockbox and encryption at rest.

Observability

M365 Copilot records when a memory is updated to organizational audit logs. The goal is end-to-end traceability: from the source content Copilot processed, to what it chose to remember, to how that memory influenced later interactions.

Today, SOC analysts can join the MemoryUpdated field, available in Defender Advanced Hunting, Defender Sentinel, and Azure Portal Sentinel Analytics, with their existing analytics to triage incidents and build new alerts on memory activity.

In summary:

Capability	What It Means for You
Task Adherence	Detect tool call misalignment with user intent, mitigating prompt injection impact. This provides protection against manipulation of memory tool calls
Unified compliance boundary	Memory governed by the same policies, retention rules, and investigation workflows as email, chat, and documents
Memory audit events	Provides visibility into when memory changes, integrated with your existing security operations
eDiscovery	Supports search and removal of AI-related data using the compliance tools you already have.

Microsoft continues to invest in AI memory security as an active, iterative program. The protections and visibility described here reflect capabilities available today, with continued hardening and enrichment underway. Capabilities described are subject to configuration, licensing, and service availability. The following section shares the framework guiding our investments.

This case study is based on MSRC cases from Johann Rehberger (first finder), Håkon Måløy, and Gal Zror.  We are grateful to the security researchers who engaged with us and informed better memory design practices through coordinated vulnerability disclosure. Their work strengthens the systems customers rely on.

A guiding framework for building safe AI memory

AI memory requires balancing personalization, capability, privacy, security, and governance.

Our AI memory strategy is guided by design principles for building safe memory systems. These principles address core failure modes that can undermine trust, security, and operability at scale.

1. Establish intent and provenance before persistence: Memory can be influenced indirectly by untrusted content, and without provenance it becomes difficult to assess whether stored information is trustworthy, appropriate to retain, or safe to use later. Memory should only be written when it reflects legitimate user intent, is aligned to the service’s purpose, and carries clear metadata about where it came from.
2. Enforce boundaries outside the model: Memory access and isolation should be controlled by deterministic systems, not model instructions. Prompting alone is not a reliable security boundary; strong enforcement prevents sensitive memory from leaking across users, agents, or tenants.
3. Treat retrieval as a risk decision: Memory that was safe to store can become stale, manipulated, or misleading over time. Uncritical retrieval can directly affect agent behavior. Treat retrieved candidate context and re-evaluated for relevance, freshness, and tampering before use.
4. Provide full lifecycle visibility for security teams: Without auditability and chain of custody, memory cannot be reliably investigated, trusted, or safely expired during incident response. Security teams need clear records of what changed, when, why, from where, and access attempts.
5. Keep users in control: Users should be able to understand how memory is shaping their experience and have meaningful controls to review, edit, and delete it. Transparency and control are essential to user trust, and they help ensure memory remains aligned with user expectations over time.

Taken together, these principles reflect where we’re headed: advancing agent capability and control together. Getting that balance right is one of the hardest challenges in the industry, but we believe the agents that scale furthest will be the ones that are also trustworthy, governable, and resilient by design.

Key takeaways

• Memory turns transient threats into persistent ones.
• You can’t secure what you can’t see. Full lifecycle logging of memory operations is the foundation of agentic safety.
• Attackers are already thinking across turns. Single-turn defenses are insufficient for AI memory systems.
• Memory expands the blast radius.
• Microsoft treats memory protections, auditability, and governance as an integral part of the broader trust and compliance architecture.
• Microsoft continues to invest in AI memory security as an active, iterative program. The protections and visibility described here reflect capabilities available today, with continued hardening underway to address emerging threats.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Guarding AI memory appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/nS46Ypg
via IFTTT

ShapedPlugin WordPress Pro Plugins Backdoored in Supply Chain Attack

Multiple WordPress plugins from ShapedPlugin were compromised in a supply chain attack after unknown threat actors managed to tamper with the official release channels and push backdoor code.

"Attackers compromised the vendor's build and distribution pipeline, injecting backdoor code into Pro plugin releases distributed through official licensed update channels," Wordfence said in an analysis published last week.

The incident affects the following plugins -

• Product Slider Pro for WooCommerce (versions before 3.5.4)
• Real Testimonials Pro (version 3.2.5)
• Smart Post Show Pro (versions before 4.0.2)

As mentioned above, it's worth emphasizing that the compromise only affects Pro plugin builds distributed through the vendor's Easy Digital Downloads (EDD) infrastructure via account.shapedplugin[.]com. The free versions of the plugins on WordPress.org are not impacted.

The supply chain compromise associated with Product Slider Pro for WooCommerce has been assigned the CVE identifier CVE-2026-49777, along with a CVSS score of 10.0, indicating maximum severity. CVE-2026-10735 (CVSS score: 9.8) is the CVE identifier for the entire incident.

The WordPress security company said the compromised versions of the plugins incorporate a loader that's triggered on every admin page, causing it to fetch a payload from a remote server ("194.76.217[.]28:2871"), install it, and activate it as a fake plugin.

Once it's activated, the malware reports the victim domain back to the server and erases itself to cover up the tracks and complicate incident response efforts. The counterfeit plugin, for its part, hides itself from the WordPress admin plugin list and is capable of capturing credentials in plaintext and two-factor authentication (2FA) codes.

It also establishes multiple persistence methods that enable arbitrary file writes via a custom REST endpoint when provided a specific authentication token, as well as drop a web shell with command execution features. Lastly, it makes use of a PHP file named "install-persistent.php," which is bundled as part of the plugin, to extract the below data -

• Full contents of wp-config.php, including database credentials, authentication keys, and debug settings
• All administrator accounts with registration dates
• Mail plugin credentials from WP Mail SMTP, Post SMTP, and Easy WP SMTP
• WooCommerce order data from the last 3 months with payment method breakdown

Once this information is displayed, the file is deleted. Evidence indicates that the attack could be a compromise of the build pipeline, as opposed to a direct poisoning of the packages.

What's particularly dangerous about this attack is that it exposes site owners who purchased legitimate licenses and installed updates directly from the vendor's official update system to malware.

Upon being notified of the issue, ShapedPlugin has confirmed the incident, adding that it's reviewing the distribution and release processes to ensure the integrity of its products going forward. New versions of the impacted plugins are expected to be released pending comprehensive security reviews and validation tests.

Site owners who have installed the malicious versions are recommended to reset all passwords, revoke and regenerate 2FA secrets for all users, review administrator accounts for unauthorized additions, and check mail plugin configurations for modified SMTP credentials.

from The Hacker News https://ift.tt/12kUciO
via IFTTT

Researchers Detail DifyTap Flaws in Dify That Could Expose AI Chats Across Tenants

Cybersecurity researchers have disclosed details of four vulnerabilities in Dify, an open-source agentic workflow platform with more than 146,000 GitHub stars, that could allow attackers to stealthily read artificial intelligence (AI) conversions from other customers' applications without requiring authentication.

The vulnerabilities have been collectively codenamed DifyTap by Zafran Security.

"Two were critical severity, two required no authentication, and three carried cross-tenant impact on Dify's multi-tenant cloud service, allowing one customer's data to be exposed to another," researchers Ido Shani and Gal Zaban said.

The security defects could have allowed attackers to read private AI chats from other customers' applications, creating a covert exfiltration channel for every message and model response.

They also made it possible to traverse Dify's internal Plugin Daemon API from unauthenticated requests and trigger cross-tenant internal API calls, as well as preview documents uploaded by other tenants and leak files across users within a tenant by attaching another user's file unique identifier.

Separately, Zafran said it also discovered that Dify's file parsing stack relied on a version of PDFium, an open-source C++ library for PDF rendering, that was vulnerable to CVE-2024-5846 (CVSS score: 8.8), a two-year-old use-after-free bug that could allow a remote attacker to potentially exploit heap corruption via a crafted PDF file.

The remaining vulnerabilities are listed below -

• CVE-2026-41947 (CVSS score: 9.1) - An authorization bypass vulnerability that allows authenticated editor users to set and enable trace configurations for any application regardless of tenant ownership.
• CVE-2026-41948 (CVSS score: 9.4) - A path traversal vulnerability that allows authenticated users to manipulate requests forwarded to the Plugin Daemon's internal REST API by exploiting insufficient URL path sanitization and access internal, private endpoints.
• CVE-2026-41949 (CVSS score: 7.5/5.9) - An authorization bypass vulnerability in the file preview endpoint ("/console/api/files/{file_id}/preview") that allows any authenticated user to read up to 3,000 characters of any uploaded document across all tenants and workspaces using only the file's UUID.
• CVE-2026-41950 (CVSS score: 6.5) - An authorization bypass vulnerability that allows authenticated users to read the full contents of files uploaded by other users within the same tenant by supplying an arbitrary file UUID in the files array of a chat-messages request.

The missing tenant ownership checks can be exploited to redirect all messages and responses from victim applications to an attacker-controlled LLM trace provider. It's worth noting that anyone can freely register for a Dify account.

"Consequently, an attacker can configure their own tracing for any application they can access as a client, which includes all publicly accessible applications," the researchers explained. "This allows an attacker to create a persistent exfiltration channel for all messages and responses sent in the application."

Following responsible disclosure, all vulnerabilities barring CVE-2026-41948 have been addressed in version 1.14.2, which was shipped last month. A fix for the pending flaw is expected to be made available in the next release of Dify.

"DifyTap demonstrates where the challenge lies in vulnerability visibility, particularly in container images, where differences between deployments can create visibility gaps that traditional scanners cannot detect," the company said.

from The Hacker News https://ift.tt/di1I2At
via IFTTT