DEV Community: Faizan Akhtar

Session Forgery + Cross-Environment Token Trust: One Request to Fleet-Wide Admin Access — Analysis

Faizan Akhtar — Tue, 20 Oct 2026 06:50:00 +0000

Original research by Md. Asif Hossain — read the full writeup here: https://medium.com/@0x0Asif/your-session-is-just-a-post-body-and-the-secret-that-signed-it-was-shared-across-environments-e5f5266566e0 · Researcher's profile: https://medium.com/@0x0Asif

Analysis by Faizan Akhtar.

One request. Zero credentials. A complete stranger becomes a support-tool administrator who can act as every customer at once — reading 13,000+ accounts across tenants, creating Premium-entitled users, minting admin sessions for any identity he names, and pivoting into the company's internal service mesh. That is the chain Md. Asif Hossain documented in a mid-October 2026 writeup based on an authorized, coordinated assessment of a multi-tenant education platform (vendor, hosts and endpoints anonymized; the tell-tales are parent↔student email mappings, per-tenant admin roles, and paid Premium entitlements). Five findings link into one escalating story — and the most instructive part is how a "fixed" vulnerability survived its own fix. This is my original analysis of what broke, the reasoning that exposed it, and what hunters and defenders should carry away.

Background

In PHP, "being logged in" is a pointer plus a server-side blob. The browser holds a PHPSESSID cookie; the server keeps the matching session store; session_start() loads that blob into the $_SESSION superglobal; and every guard reads from it. The entire model rests on one assumption: the client can only influence $_SESSION indirectly. The moment a client can write into $_SESSION directly, every downstream auth check becomes attacker-controlled input.

The target is a multi-tenant education service with a support console that is cross-tenant by design — its whole job is to reach all customers. Inside it sat an internal "manual import" handler: a utility endpoint built for operations staff, wired to a test shim. The writeup is explicit that this was an authorized assessment with tight safety discipline — writes hit only controlled test identifiers, every mutation was reverted, and customer PII is redacted. What follows is an analysis of the findings, not a reproduction of the requests.

The Vulnerability

Five linked findings — the first two are the core; the other three are what the core unlocked.

1. Pre-auth session forgery — an auth-ordering inversion. The import handler started the session, decoded the JSON body, and copied the client-supplied session block straight into $_SESSION when a flag was set — before loading the auth gate. The gate then judged email and role on data the requester had just written: setup ran before authentication (CWE-501 → CWE-287), so the gate certified the forgery. Two details carry the lessons. The role check demanded the integer 0 (strict comparison), and PHP's json_decode preserves types — a body carrying the number 0 passed while "0" failed. And the request did not even need to "succeed": the handler issued the cross-tenant support_tool_bearer cookie before its own XSRF/validation check rejected the request. HTTP 400 came back carrying a working fleet-wide credential in Set-Cookie. The status code lied; anyone who stops reading at the status line misses the finding.

2. Cross-environment session acceptance — the fix that fixed nothing. The vendor patched the forge path on production, which exposed the second flaw: the QA/stage cluster still hosted the same shim, the bearer was signed with a secret shared across QA/stage and production, and the cookie was scoped to the apex domain. A QA-minted credential was therefore honored as a support-tool admin session on production — cookie scope carried it to every subdomain, and fleet-wide signature trust validated it since the token carried no environment binding. Fixing production while the same artifact ran on QA was cosmetic.

3–5. What the bearer unlocked. Cross-tenant read: the support console's read handlers returned the federated roster — 13,000+ accounts across all clusters, 3,001 in a single cluster — plus per-tenant config and parent↔student email mappings, no ownership checks. The causality control makes it undeniable: the same handler with no cookie returned 401 "BAD TOKEN FORMAT" — proving the endpoint is genuinely authenticated and the token is real (and incidentally disclosing verbose errors). Cross-tenant write: the same bearer drove mutating handlers accepting a client-supplied tenant ID with no permission gate or tenant-ownership check — alias admin accounts with Premium entitlement bits set, verified, then reverted. And SSRF: a user-controlled cluster parameter drove server-side requests from the support tool, and the response echoed the internal support API's own auth token back — CWE-918 with credential disclosure, a foothold inside the internal service mesh.

How It Was Found

The writeup does not narrate the recon path to the shim — it documents the reasoning chain that makes the find reproducible. Reconstructed from the findings:

The starting question: what happens before the auth check? Utility endpoints — manual imports, restore-debug-session, re-hydrate-state handlers — are written for authenticated admins, given no auth of their own, then exposed by a routing rule or leftover test shim. Enumerate those handlers and test each against the ordering invariant.

The payload work shows type discipline: crafting the forged block around PHP's strict comparison and json_decode's type fidelity. The observation work is sharper: noticing a 400 response carried a Set-Cookie, and grasping what it meant — the credential is minted before validation fails. Most testers read status codes; this one read headers.

Then the deployment-awareness most reports skip. The platform sat behind an AWS ALB with sticky sessions, and the forged session lived on exactly one backend node — replaying only PHPSESSID could land on a node that had never seen the forgery and return 401. The fix: carry the ALB's own cookie forward in a cookie jar. And after the vendor announced the production fix, the reasoning did not stop at "patched" — it asked where else the code runs. QA still hosted the shim. Then it asked what the token was worth beyond the session: chasing the bearer to production, where shared signature trust and apex cookie scope turned a QA artifact into production admin access. Chase the token, not the session.

Why It Worked

Three layers trusted something they should not have, and an operational failure cemented all three. The handler trusted request data as session state — setup-before-auth meant the gate certified forged input. The deployment trusted the environment boundary — a shared signing secret plus an apex-scoped cookie erased the line between a test cluster and the live fleet. The support tool trusted its network position — cross-tenant by design, with handlers that never checked tenant ownership, because "internal" was treated as safe.

And the operational failure: the fix addressed one environment while the identical artifact remained reachable in another. Multi-tenancy was the amplifier — a session bug on a single-tenant app compromises one account; the same bug behind a cross-tenant support console, a tool whose purpose is reaching every customer, becomes fleet-wide. The writeup's summary is precise: unauthenticated, self-contained, identity-granting, fleet-wide. One request converted a stranger into an administrator who could act as every customer at once.

Lessons for Hunters

Ask "what happens before the auth check?" on every endpoint. The single most valuable review question in the writeup; it generalizes across languages: find the gate, then read upward.

$_SESSION = $request is a pattern-matchable red flag — but grep smarter. The naive grep for direct $_SESSION assignment misses the common real form: a keyed loop copying each input key into the session, plus array_merge, extract($_POST), parse_str, session_id($_GET[…]), unserialize, and framework wrappers. A hit is a signal, not a verdict — for each one, answer two questions: where does the data come from, and is the auth check before or after this line?

Never trust the status code. A 400 carried a working fleet-wide credential here. Read the full response on failures — the security outcome can diverge from the HTTP outcome.

Carry the load balancer's cookies. Sticky sessions pin forged state to one backend node; replay the LB cookie in a cookie jar or your exploit "mysteriously fails" — and mysterious failures get abandoned.

After "fixed on prod," ask where else the code runs. QA/stage drift, leftover clusters, and forgotten subdomains are where theoretical becomes live — a credential minted in one environment may be honored in another when secrets are shared.

Prove causality, then write it up. The 401-without-cookie control makes the finding undeniable — and its verbose error was a bonus finding.

Mitigation

The structural fixes, distilled from the writeup's remediation section:

Never assign request data to $_SESSION wholesale — set only specific, validated keys, and only after authentication succeeds. Enforce the ordering invariant (authenticate → authorize → then mutate) in middleware.
Store only an opaque user ID in the session; re-derive role, tenant, and email from a trusted store on every request. Never carry authorization data in a session blob that can be minted elsewhere.
Remove test shims from every environment, not just production — grep all clusters for the harness artifact and verify it 404s in the release checklist.
Bind token trust to the issuing environment: never share a signing secret across QA/stage/prod — use per-environment keys, put iss/aud/env/tenant claims in the token, validate them everywhere, and scope session cookies to the narrowest host.
Harden internal cross-tenant tooling as if it were public: per-endpoint permission gates, tenant-ownership checks on every read and write, and logging/alerting on every impersonation action.
Detect the class live: alert on $_SESSION mutation on an unauthenticated request, plus standard session hardening (strict mode, secure/HttpOnly/SameSite cookies, regenerate ID on privilege change).

If you found this breakdown useful, read the earlier entry in this writeup-analysis series: my analysis of how Hacktron chained a malicious HEIF image through an SSO flaw to internal repo access at OpenAI — another story of trust crossing a boundary it should never have crossed — https://faizanakhtarcyber.blogspot.com/2026/10/openai-libheif-sso-account-takeover-analysis.html.

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-108598: Floci Velocity SSTI Code Injection Vulnerability — Analysis & Mitigation

Faizan Akhtar — Sat, 17 Oct 2026 01:41:53 +0000

Originally published at https://faizanakhtarcyber.blogspot.com/2026/10/cve-2026-108598-floci-velocity-ssti-rce-analysis.html

Floci, the open-source AWS API Gateway emulator, shipped version 2.2.0 this month to fix CVE-2026-108598, a critical server-side template injection vulnerability that hands unauthenticated attackers full operating-system command execution on the host. An attacker creates a REST API with a MOCK integration, drops in a Velocity mapping template that uses $util reflection, and walks straight into Java's Runtime or ProcessBuilder. It is also a textbook failure of identity access management: the endpoint that creates APIs and writes executable templates asks for no identity at all.

Summary

Floci emulates AWS API Gateway for local development and testing, letting teams build and test API definitions without touching real AWS infrastructure. Its VtlTemplateEngine component renders Apache Velocity mapping templates for MOCK integrations — the feature that lets a fake API return canned responses. CVE-2026-108598 is a CWE-94 code injection flaw: Floci 1.1.0 before 2.2.0 placed no restrictions on those Velocity templates, and creating a REST API with a MOCK integration required no authentication.

The attack needs exactly one unauthenticated request: create a REST API whose MOCK integration carries a mapping template. Velocity templates expose a $util object, and through reflection the template can reach java.lang.Runtime or ProcessBuilder — at which point the "template" is simply a shell command, and the Floci JVM executes it with the service account's privileges. Full OS command execution, no credentials, no user interaction.

A public proof-of-concept has been published, which compresses the window between disclosure and weaponization to nearly zero. If your Floci instance is reachable from any network you do not fully trust, treat it as an exposed remote shell until proven otherwise.

Severity

CVE ID: CVE-2026-108598
CVSS: 9.8 Critical — VulnCheck CNA scoring
CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Weakness: CWE-94 — Improper Control of Generation of Code ('Code Injection'); also tagged CWE-78 (OS Command Injection)
Attack requirements: none — unauthenticated, remote, low complexity, no user interaction
Impact: arbitrary OS command execution on the host running the Floci JVM — full system compromise of that box
Exploited in the wild: no confirmed reports; a public PoC exists, which historically accelerates exploitation

The vector is the maximum-severity shape: network, low complexity, zero privileges, total impact on confidentiality, integrity, and availability. There is no interaction gate and no privilege gate — the only gate is network reachability.

Affected Versions

Floci 1.1.0 before 2.2.0 — every release in that range is affected
Fixed in: 2.2.0 (restricts the Velocity template engine)
Component: VtlTemplateEngine — the Velocity mapping-template renderer for MOCK integrations
Exposure: any Floci instance reachable over the network — developer laptops on shared networks, shared test servers, CI runners, and any deployment bound to 0.0.0.0 instead of localhost

The dangerous misconception is "it's just a local dev tool." Dev tools run with developer privileges, on machines holding cloud credentials, SSH keys, and source code — and they are routinely left listening on shared or corporate networks. "Local" describes the intent, not the exposure.

Technical Analysis

From $util to Shell: The Classic Velocity Escalation

Server-side template injection in Apache Velocity follows a well-worn escalation path. Velocity templates are meant to be presentation logic — $variable substitution and simple directives — but the engine historically exposes enough of the Java object graph to escape the sandbox. The $util object in a mapping template is the foothold: through it, the template can obtain a Class reference, and from there use reflection to load java.lang.Runtime and call getRuntime().exec(), or instantiate ProcessBuilder directly. Each step is "legitimate" template functionality; the chain as a whole is arbitrary command execution.

Here is the part that should unsettle emulator authors: in a MOCK integration, the template is not smuggled in through a user profile field or a comment box — it is the integration definition itself. The attacker is using the product's documented feature exactly as designed. The vulnerability is not that Velocity can reach Runtime (that is a known, hard-to-fully-sandbox property of the engine); it is that an unauthenticated stranger is allowed to author integrations. The template engine is the weapon, but the missing authorization check is the unlocked armory door.

An Identity Access Management Failure, Not Just a Template Bug

Strip away the template details and CVE-2026-108598 is an identity access management failure. In real AWS API Gateway, creating a REST API and defining its integrations is a privileged operation gated by IAM policies — you prove who you are, and the policy decides what you may do. Floci emulates the API surface of API Gateway but emulated none of the authorization boundary: anyone who could reach the service could create APIs and write executable templates, with no identity presented and no policy evaluated.

This is the recurring sin of developer emulators and local service mocks: they reproduce the functionality of the cloud service faithfully while silently dropping the security model. Every emulator, mock, and localstack-style tool in your stack deserves one hard question: which authorization checks did the emulation leave out, and who can reach the ports where those checks are missing? As a pentest finding, "emulator reachable without authentication" writes itself — the only work is checking which ones your target runs.

Dev Tools With Server Privileges

Consider where Floci actually runs. On a developer laptop, a compromise means the attacker's code executes alongside the developer's AWS credentials, SSH keys, and source checkouts — a straight path to cloud and code-infrastructure takeover. On a shared test server or CI runner, it means execution on a box that likely holds deployment tokens and pipeline secrets. Emulators are frequently started with permissive network bindings (0.0.0.0 for container access or team sharing) and then forgotten, and they rarely appear in asset inventories because "it's just a dev tool."

The data-integrity angle is what incident responders will feel first. A MOCK integration's template controls what the fake API returns — which means a compromised Floci can silently serve manipulated responses to every developer and test suite pointed at it. Poison the mock and you poison the tests: passing builds against lying APIs, integration tests that validate attacker-shaped data, and a false sense of correctness that survives long after the compromise.

Why This Matters

Unauthenticated remote code execution on network-reachable infrastructure is the season's dominant pattern — a perimeter box owned without credentials, a gateway turned into a launchpad. Floci extends the pattern somewhere defenders rarely look: the development toolchain. The perimeter is no longer just the firewall and the VPN — it is every service listening on your laptop, your test server, and your CI network.

What does vulnerable mean in the context of CVE-2026-108598? It means a tool you installed to pretend to be AWS can be turned into a real shell on your machine by anyone on your network, with no password and no phishing required. What is data integrity worth when a template can run shell commands? Nothing — once the mock server is owned, every "passing" test it serves is evidence manufactured by the attacker. Patch the emulator, then question everything it told you while it was exposed.

Mitigation

Upgrade immediately to Floci 2.2.0 — the release restricts the Velocity template engine and closes the injection path
Kill the network exposure: bind Floci to localhost only; never run it on 0.0.0.0 on shared, corporate, or CI networks
Inventory every instance: search developer laptops, shared test servers, containers, and CI runners for Floci — un-inventoried dev tools are unpatched dev tools
Assume breach if it was exposed: any instance reachable from an untrusted network should be treated as compromised — rotate credentials and tokens that lived on that host, and rebuild rather than just patching
Distrust its recent answers: if the instance served MOCK responses while exposed, re-run affected test suites against a patched instance — a compromised mock can make failing code look green
No workaround short of the patch besides strict network isolation — restricting who can reach the service is the only mitigation on affected versions

References

NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-108598
VulnCheck advisory: https://www.vulncheck.com/advisories/floci-1.1.0-before-2.2.0-rce-via-api-gateway-vtl-mapping-templates
ThreatAft: https://threataft.com/articles/code-injection-duo-cve-2026-108551-108598
Floci 2.2.0 release (fix): https://github.com/floci-io/floci/releases/tag/2.2.0

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-108551: openapi-typescript-codegen Handlebars Code Injection Vulnerability — Analysis & Mitigation

Faizan Akhtar — Sat, 17 Oct 2026 01:40:51 +0000

Originally published at https://faizanakhtarcyber.blogspot.com/2026/10/cve-2026-108551-openapi-typescript-codegen-handlebars-injection-analysis.html

On October 10, 2026, the NVD published CVE-2026-108551, a critical code injection vulnerability in openapi-typescript-codegen, the npm package that converts OpenAPI documents into typed TypeScript API clients — downloaded roughly 600,000 times a week. A single apostrophe inside a malicious API specification can break out of a generated string literal and inject live JavaScript into every client the tool produces. For the security of cyberspace, the twist is the target: this bug does not attack your application — it attacks your build pipeline, poisoning the code before your application even exists.

Summary

openapi-typescript-codegen is a Node.js library that reads an OpenAPI (Swagger) document and generates a ready-to-use TypeScript API client. CVE-2026-108551 is a CWE-94 code injection flaw in the Handlebars templates the generator uses to build that client. The templates interpolate spec-controlled values with Handlebars' triple-stash syntax ({{{...}}}) — which writes values out unescaped — directly inside single-quoted JavaScript string literals. Affected slots include BASE: '{{{server}}}' and VERSION: '{{{version}}}' in the generated config, method: '{{{method}}}' and url: '{{{path}}}' per request, and '{{{prop}}}': as parameter keys for path, cookie, header, query, and form params.

The result: anyone who controls or influences an OpenAPI document processed by your build — a vendor's published spec, a partner's API definition, an internal service registry, a public repo — can embed a single quote plus a JavaScript payload in a path key, a parameter name, servers[0].url, or info.version. The generated client then contains executable attacker code that runs when the client is imported or a service method is called.

The sting: no patched version exists. Version 0.31.0 (June 2026) is the newest release, and the promised fix — including an npm deprecation in favor of its successor — was never applied. Every released version, 0 through 0.31.0, is affected.

Severity

CVE ID: CVE-2026-108551
CVSS 3.1: 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CVSS 4.0: 9.3 Critical (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)
Weakness: CWE-94 — Improper Control of Generation of Code ('Code Injection')
Reported by: researcher George Chen; CNA: VulnCheck
Attack requirements: none against the pipeline — the attacker only needs influence over an OpenAPI document the victim's tooling consumes
Impact: arbitrary JavaScript execution in the build environment (secrets theft, CI/CD compromise) and in every consumer of the generated client (XSS-equivalent in browsers)
Exploited in the wild: no confirmed reports; not in the CISA KEV catalog

The 9.8 is honest: network-reachable, trivial complexity, zero privileges, full confidentiality/integrity/availability impact. The "network" here is your dependency supply chain — which is reachable by design.

Affected Versions

openapi-typescript-codegen 0 through 0.31.0, inclusive — all 109 published npm versions
Fixed in: nothing — no patched release exists; 0.31.0 (June 20, 2026) is still the latest on the registry
Vulnerable injection points: request path keys, path/query/header/cookie/form parameter names, request-body media types, response header names, servers[0].url, and info.version
All generated HTTP clients affected: fetch, axios, xhr, node, and angular variants
Exposure: any pipeline that generates clients from specs you do not fully control — vendor specs, partner APIs, service registries, auto-ingested remote URLs in CI

If your CI runs generation automatically on every build against a remote spec URL, you are running attacker-influenced code generation on a schedule, inside an environment that holds your deployment secrets.

Technical Analysis

Three Braces and a Single Quote

In Handlebars, {{value}} HTML-escapes its output while {{{value}}} — the triple-stash — writes it raw. Template authors reach for the triple-stash when the value legitimately contains characters that escaping would mangle, like the & in a URL. The generator's templates needed raw server URLs and paths, so the author wrote BASE: '{{{server}}}', — and in doing so, handed the OpenAPI document direct write access to the generated JavaScript source.

The exploit is textbook string-literal breakout. Suppose servers[0].url is https://api.example.com/'; PAYLOAD; //. The generator emits BASE: 'https://api.example.com/'; PAYLOAD; //', — the first quote closes the literal, the payload executes as ordinary JavaScript, and the trailing // comments out the leftover quote. From there the payload does anything JavaScript can do in that context: in a Node build step it reads process.env and exfiltrates CI secrets; in a browser bundle it runs with the application's origin and session.

Nobody code-reviews a code generator's output line by line — that is the point of using one. Linters won't flag it, type-checkers won't flag it, and once committed, the payload inherits the trust of your own repository.

Supply-Chain Arithmetic: Poisoning Code Before It Exists

Most supply-chain attacks poison something you install — a compromised package, a typosquatted dependency. CVE-2026-108551 poisons something you generate, which is harder to detect: the malicious artifact is produced by your own trusted tooling, then signed, built, and shipped by you. The trust boundary crossed is not "do I trust this package" but "do I trust every OpenAPI document my tooling has ever consumed" — and most organizations cannot answer that, because specs flow in from vendors, partners, and registries with no integrity checks.

Do the arithmetic: one compromised vendor spec, auto-ingested by CI across ten client teams, produces ten poisoned generated clients, each shipped to production, each executing the attacker's JavaScript. The blast radius multiplies at every layer — build environment, generated code, downstream consumers — while the evidence (a quote character in a YAML file somewhere) stays nearly invisible. This is why the security of cyberspace increasingly depends on build-pipeline hygiene, not just application code.

Pentest Playbook: Weaponizing an OpenAPI Spec

On a pentest, this vulnerability gives you a phishing-free path into the build environment. The recon is simple: OpenAPI documents sit at predictable locations (/openapi.json, /v3/api-docs, /swagger.json) or ship to partners as integration artifacts. During scoping, determine whether the target generates clients — check CI configs for codegen steps, look for generated client directories, and ask which specs feed them.

A pen test demo: (1) identify an auto-ingested spec (a vendor integration or registry entry you can influence); (2) inject a quote-breakout payload into info.version or a parameter name; (3) show the generated diff containing live JavaScript; (4) demonstrate execution at import time in the build container — reading a canary secret from the environment proves CI compromise without touching production.

Why This Matters

Build pipelines are the soft underbelly of modern software delivery. The tool that writes your code for you becomes the attacker's code writer, inheriting every privilege your build holds.

What does vulnerable mean when the flaw lives in your build tools? It means your application can be compromised without a single bug in your application — the poison enters one step earlier, in the generated code you never wrote and never reviewed. Why should every pentest scope include the code generator? Because attackers follow trust, and nothing in your organization is more trusted — or less scrutinized — than the tooling that produces your source code.

Mitigation

There is no patch — 0.31.0 is the latest release and no fixed version exists. Mitigation is procedural until the maintainer ships a fix.
Generate only from specs you trust: stop auto-generating clients from remote spec URLs in CI. Vendor specs locally, review them, and generate from the vendored copy.
Review generated-code diffs: treat generated output as untrusted input — require human or automated review of every generated diff before it is committed or built.
Pin and audit: pin the package version, run npm ls openapi-typescript-codegen across your repos to find every consumer, and flag any pipeline that ingests third-party specs.
Sandbox the generation step: run codegen in an ephemeral container with no deployment secrets in the environment, so a successful injection still cannot reach anything valuable.
Evaluate maintained alternatives: the package has seen no release since June 2026 and the promised deprecation never happened — plan a migration path to an actively maintained generator.

References

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-96889: Next.js Image Optimization RCE Vulnerability — Analysis & Mitigation

Faizan Akhtar — Sat, 17 Oct 2026 01:39:49 +0000

Originally published at https://faizanakhtarcyber.blogspot.com/2026/10/cve-2026-96889-nextjs-image-optimization-rce-analysis.html

On October 14, 2026, Vercel shipped an out-of-band security release for Next.js — versions 16.4.1 (Active LTS) and 15.5.28 (Maintenance LTS) — to fix CVE-2026-96889, a critical remote code execution vulnerability in the framework's Image Optimization API. A crafted SVG file processed by the image pipeline can corrupt server memory and escalate into arbitrary code execution, with no login and no user interaction. For the security of cyberspace, the scary part is the blast radius: Next.js powers millions of production sites, and the vulnerable range spans every release line from 10.0.0 onward.

Summary

CVE-2026-96889 is a use-after-free (CWE-416) flaw in librsvg, the SVG rendering library that Next.js reaches through its bundled sharp image-processing package. When the Image Optimization API (or next/og image generation) processes an SVG document containing nested XML inclusions (XIncludes) with duplicate entity declarations, the library frees an XML entity that the parser is still using. An attacker who slips a malicious SVG into that pipeline — via an optimized image URL or a social-image endpoint — can turn memory corruption into remote code execution on glibc-based Linux servers.

Two details make this one unusual. First, the underlying librsvg bug was public since September 23 and fixed in sharp 0.35.5 on September 27 — but Next.js shipped its fix only on October 14, a two-week lag. Second, this is the third image-processing code-execution flaw in Next.js since August: an August libheif bug reachable through crafted AVIF files, a September next/og SVG flaw, and now this librsvg use-after-free. The image pipeline has become the framework's most reliable source of critical vulnerabilities.

Vercel rates the Next.js exposure as CVSS 9.5 Critical — fully network-reachable, no privileges required — because the framework's image endpoint turns a local file-parsing bug into a remote one.

Severity

CVE ID: CVE-2026-96889 (GHSA-2464-fhr4-w9xw)
CVSS 4.0: 9.5 Critical — Vercel/Next.js advisory rating for the framework exposure
Underlying librsvg flaw: CVSS 3.1: 7.8 High (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) — Red Hat CNA scoring
Weakness: CWE-416 — Use After Free
Attack requirements: none — unauthenticated, remote, low complexity, no user interaction (per the Next.js advisory)
Impact: remote code execution on glibc-based Linux (Debian/Ubuntu containers); crash-only on some Node.js builds and musl-based (Alpine) images
Exploited in the wild: no confirmed reports as of October 15, 2026

Read the two scores as context: the library bug needs someone to open a malicious file; the framework exposure lets anyone on the internet be that someone.

Affected Versions

Next.js 10.0.0 through 15.5.27 and 16.0.0 through 16.4.0 — the widest vulnerable range of any Next.js disclosure this year
Fixed in: 15.5.28 and 16.4.1
Underlying library: sharp before 0.35.5 (bundles librsvg before 2.63.2) — 16.4.1 fixes it purely by bumping the bundled sharp
Platform scope: code execution applies to Next.js on glibc-based Linux; Alpine/musl builds are not named as affected — confirm your base image before assuming safety
Reachability: apps with dangerouslyAllowSVG enabled in the Image Optimization config, and any app using next/og ImageResponse on the Node.js runtime

The sibling fixes in this release — a 9.5 use cache RCE and an 8.2 Server Actions DoS — have no workaround. But for the SVG flaw, sharp itself is the fix vector: getting bundled sharp to 0.35.5+ closes the hole.

Technical Analysis

The SVG That Fires Back: Anatomy of a Use-After-Free

A use-after-free (CWE-416) means the program releases a chunk of memory while a pointer to it is still live; later, attacker-influenced data gets written into that freed slot, and the stale pointer follows it somewhere the attacker chooses. In librsvg, the trigger is an SVG document with nested XML inclusions (XIncludes) carrying duplicate entity declarations — the XML parser frees an entity that is still referenced, and subsequent parsing operations reuse the dangling reference. Crafted carefully, that reuse corrupts heap metadata or function pointers, and in a Node.js server process, heap corruption is a short walk from arbitrary code execution.

Both end up calling sharp, which calls librsvg, which parses attacker-shaped XML — a parser never designed to face the internet, placed there by the framework anyway.

Pentest Perspective: Your Image Pipeline Is a Parser With Server Dreams

As a pentest target, the Next.js image optimizer is close to ideal for an attacker: it is unauthenticated by design, it performs complex parsing of attacker-controlled formats, and it runs inside the server process with the server's privileges. During a pen test, this is exactly the kind of endpoint I fingerprint first — /_next/image?url=... is a beacon announcing "here is a file parser you can reach from the internet."

The exploitation chain a tester would map looks like this: (1) confirm the app serves optimized images or next/og endpoints; (2) deliver an SVG with nested XIncludes and duplicate entities; (3) observe crashes or hangs to confirm memory corruption; (4) tune the heap layout toward control. Whether step 4 lands as code execution or a crash depends on the server's Node.js build — official Node binaries lack hardening against this memory-attack class. Hardened builds yield a reliable crash (a DoS primitive); soft builds yield a shell.

Three Strikes: Why Image Processing Keeps Breaking Next.js

August: libheif, reachable through crafted AVIF files. September: next/og, where attacker-controlled text altered the generated SVG. October: librsvg, through nested XIncludes. Three different libraries, one pattern — every image format is a parser, every parser is a state machine fed untrusted bytes, and Next.js keeps chaining new parsers into its hottest request path.

Your application's security now depends on an SVG library, bundled inside an image package, bundled inside a framework — three layers down. When the fix sits upstream for two weeks before your framework ships it, your patching SLA is the slowest layer's, not the fastest.

Why This Matters

Next.js is not a niche framework. It runs everything from startup landing pages to Fortune 500 storefronts, which means a remotely reachable image-parser RCE is effectively a skeleton key to a meaningful slice of the modern web.

What does vulnerable mean in the context of CVE-2026-96889? It means your image optimizer — a feature you probably think of as cosmetic — can turn a picture request into a server shell, with no login and no click. If your app exposes /_next/image or generates next/og cards on the Node runtime, assume you are in the blast radius until patched. How should a pentest scope treat image handling after CVE-2026-96889? Stop treating it as a frontend concern. It is a memory-unsafe parsing pipeline running inside your server process, and it deserves the same patching urgency as your authentication code.

Mitigation

Patch immediately: npm install [email protected] or npm install [email protected] — the sibling flaws have no workaround, so upgrade regardless
Targeted fix for the SVG flaw: ensure the sharp version used by Next.js is 0.35.5 or later (carries librsvg 2.63.2) — upgrading Next.js pulls this in automatically
No complete workaround for the release as a whole; for the SVG flaw specifically, disabling dangerouslyAllowSVG and auditing next/og usage reduces exposure but does not fix the library
Verify your base image: code execution is scoped to glibc-based Linux — confirm whether your containers are Debian/Ubuntu or musl-based Alpine rather than assuming
Hunt for exposure: check access logs for repeated /_next/image SVG requests since September 23, plus crashes or worker restarts in the image pipeline
Harden going forward: pin and audit transitive image-processing dependencies, and put the image pipeline inside your pen test scope on every engagement

References

NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-96889
The Hacker News: http://thehackernews.com/2026/10/nextjs-ships-out-of-band-patch-for-two.html
GBHackers: https://gbhackers.com/nextjs-svg-image-processing-vulnerability/
The CyberSec Guru: https://thecybersecguru.com/exploits/nextjs-critical-rce-vulnerabilities-cve-2026-96889/

Report by Faizan Akhtar — The Cyber Security Researcher

OpenAI Account Takeover via libheif Heap Overflow and SSO Flaw: How Hacktron Chained a Malicious HEIF Image to Internal Repo Access — Analysis & Lessons

Faizan Akhtar — Fri, 16 Oct 2026 06:30:14 +0000

Original research by the Hacktron AI team (Harsh Jaiswal, Mohan Pedhapati, Rahul Maini) — read the full writeup here: https://www.hacktron.ai/blog/hacking-openai · Researcher's profile: https://www.hacktron.ai

Analysis by Faizan Akhtar.

A single photo upload was the entire entry point into one of the most closely watched companies on the planet. In July 2026, three researchers from Hacktron AI turned a crafted HEIF image into remote code execution on OpenAI's community forum, then crossed a far more consequential boundary: an identity flaw in OpenAI's single sign-on let them take over the ChatGPT and Codex accounts of anyone who had merely signed into that forum, including employees. One employee's GitHub-connected Codex then opened a pull request inside OpenAI's private internal monorepo — proof of access delivered, no code read, testing stopped. This is my original analysis of their publicly disclosed research: how the two bugs were found, why the chain worked, and what hunters and defenders should take from it.

Background

Harsh Jaiswal, Mohan Pedhapati and Rahul Maini — working as Hacktron AI — set out to probe the security posture of frontier AI companies and settled on OpenAI's community forum at community.openai.com, which runs on Discourse and offers "Sign in with OpenAI". What they found was not one vulnerability but two defects with a bridge between them: a memory-corruption flaw in the forum's image pipeline, and an SSO weakness that treated the forum's front door as a hallway into employees' accounts.

The timeline reads like a sprint. On July 23 they traced the forum's HEIF upload path to the vulnerable decoder; on July 24 they had a working exploit with ASLR disabled; on the morning of July 25 they had reliable code execution against the live forum, and that afternoon they opened the proof-of-access pull request and stopped testing — discovery to internal-repo access in under 72 hours. They reported the SSO-side finding through OpenAI's Bugcrowd program; OpenAI fixed it roughly 14 hours after submission and paid $6,500 for the OpenAI-side finding only (the forum itself was outside the bounty scope). The forum-side issue went to Discourse's HackerOne program: received on a Saturday, answered on a Sunday, fixed on Monday. The writeup was published in mid-September 2026, alongside a wider campaign tracing the same decoder weakness across other platforms.

The Vulnerability

A heap buffer overflow in libheif, reachable through the forum's image pipeline. Discourse checks uploads with FastImage, but FastImage could not parse HEIF files, so those uploads were diverted to ImageMagick's magick command — which delegates HEIF decoding to the libheif library. That delegation exposed the raw libheif parser to attacker-controlled files, and the decoder contained a heap buffer overflow yielding out-of-bounds read and write primitives. The supply-chain detail makes this case-study material: the faulty code had already been corrected upstream, but the commit was never flagged as a security fix and got no CVE. Treated as ordinary maintenance, it was never backported — the Discourse Docker image (Debian 12) shipped libheif 1.19.7 still vulnerable, and Debian 13 shipped 1.19.8 vulnerable too. A fix invisible to the people who decide what to backport is, from the attacker's perspective, no fix at all.
An OpenAI SSO identity flaw that crossed the trust boundary. The forum used "Sign in with OpenAI" through auth.openai.com. The second bug lived in how OpenAI's identity layer scoped that sign-in: with code execution on the forum, the researchers could take over the ChatGPT and Codex accounts of anyone signed in through that SSO flow — employees included — with no interaction from the victims. Because ChatGPT and Codex connect to services like GitHub, Slack and email, the blast radius extended into everything those connections could touch. The escalation is not Discourse-specific: any compromised service sharing that SSO arrangement would have offered the same path; the forum was merely the proof.

How It Was Found

This is a dependency-auditing find elevated by methodical pipeline tracing, and the discovery order matters.

The team started with an unglamorous question: where does this application hand files it cannot understand to someone else's parser? Following Discourse's upload handling, they spotted the FastImage-to-ImageMagick detour for HEIF — a format-exception branch reviewers skim past because it exists for compatibility, not security. They then asked an AI model to inspect the installed libheif package inside the Discourse Docker image, and it reported that certain fixes had never been backported. The model did not invent a zero-day; it found a genuinely unpatched, publicly committed bug and recognized its security significance. The flaw was "known" to upstream and invisible to downstream — the model's job was noticing the gap.

Opus 4.8 then built an exploit that worked only with ASLR disabled; hours after Anthropic released Opus 5, the newer model produced a working exploit that the team ported to the forum's x86-64 and jemalloc configuration. By 06:00 UTC on July 25 they had confirmed local RCE through an image upload. They tested against their own Discourse Cloud instance first — framed as a CTF target, since the model refused to aim at a remote production system — and only then ran it against community.openai.com at around 10:00 UTC. The final act: an employee's Codex, connected to OpenAI's GitHub organization, was instructed to open a single harmless pull request — #1186742 — in the internal monorepo. No source code was read or downloaded. Then testing ended.

That restraint is the model for the strongest impact demonstration that touches no sensitive data: a single, obviously harmless artifact created inside the target's own system of record — a claim about access converted into evidence of access.

Why It Worked

Every layer trusted the layer above it in a slightly different way, and nobody owned the boundary between them. The image pipeline trusted format detection: a file calling itself a photo was fed to a native decoder running with the application's privileges. The distribution trusted the upstream commit message: a fix without a CVE number looked like routine maintenance, so the backport never happened and the vulnerable library shipped for months. And the identity layer trusted the forum's front door: the SSO implementation failed to constrain a forum sign-in to forum-level access, so forum compromise became identity-wide compromise. That is the identity access management failure at the heart of the story — access was scoped to "this person proved who they are", not to "this person proved who they are, on this low-trust property, for this purpose".

The uncomfortable part: nothing here required a zero-day. The memory corruption was publicly committed upstream; the SSO issue was a configuration decision. What was new was the combination and the speed. The team's epilogue says it plainly: security has long relied on the quiet protection of complexity — bugs might be public, but weaponizing them demanded rare skill and time. When models compress months of exploit development into hours, that protection thins, and threat models must price in an adversary who can afford to try everything.

Lessons for Hunters

Map every parser your target delegates to. The find began where the application's own code ended: at the handoff to ImageMagick and then libheif. For every upload feature, trace the file past the application's checks and ask which native library eventually touches the bytes. Format-exception branches are where the interesting parsers hide.

Hunt unflagged upstream fixes. A security fix that never got a CVE is a backport that never happens. Diff upstream commits against the versions your target's distributions actually ship, and treat "fixed upstream, unflagged" as a live vulnerability class.

Treat shared SSO as shared trust — then attack the weakest party. Wherever a low-trust property shares single sign-on with high-value accounts, the property's security posture becomes the accounts' security posture.

Test inside the real artifact. The vulnerable component lived in the Docker image's Debian layer, not in Discourse's application code — a web-UI update would never have replaced it. Scope your target as the deployable unit (container image, not repo) and test what actually ships inside it.

Prove impact without touching the crown jewels. The pull-request proof is the model for responsible maximum-impact demonstration: an undeniable, reversible, in-system artifact requiring exactly the access claimed — nothing more.

Mitigation

Rebuild self-hosted Discourse from the image, not the UI. Run git pull and ./launcher rebuild app — a web-interface update alone may not replace the vulnerable libheif inside the Docker image.
Update the native libraries and check backports. Install the latest security-patched libheif and libde265. Discourse's advisory GHSA-vhm9-85gw-x335 (July 28, 2026, CVSS 8.8) lists patched releases 2026.7.0, 2026.6.1, 2026.5.2 and 2026.1.6, and newer Discourse versions sandbox image processing as defense in depth.
Isolate image processing. Decoder complexity guarantees future bugs in this family. Route untrusted images through hardened, ephemeral sandboxes, restrict accepted formats via ImageMagick's security policy, and disable HEIF/AVIF decoding where the business does not need it.
Scope SSO sessions to the issuing property. A community-forum sign-in must not mint sessions usable against employee-grade accounts and their connected integrations. Audit every SSO relying party for this overreach, and shrink write scopes on connector grants attached to AI-agent accounts.
Detect the probing, not just the payload. The campaign uploaded thousands of malformed images and was detected by only one company. Alert on decoder crashes and repeated malformed uploads to the same pipeline — that is the sound of someone building an exploit.

If you found this breakdown useful, read the earlier entries in this writeup-analysis series: my analysis of Pirikara's chained cross-account JavaScript execution in Basecamp's Fizzy — https://faizanakhtarcyber.blogspot.com/2026/10/basecamp-fizzy-cross-account-javascript-execution-analysis.html — and of 6r1ff1n's DuckDuckGo CI/CD RCE — https://faizanakhtarcyber.blogspot.com/2026/10/duckduckgo-pull-request-target-rce-writeup-analysis.html.

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-76519: Cisco Secure Email Gateway Path Traversal RCE Vulnerability — Analysis & Mitigation

Faizan Akhtar — Fri, 16 Oct 2026 01:48:02 +0000

On October 14, 2026, Cisco published advisory cisco-sa-esa-afw-zqYJkjxp for CVE-2026-76519, a critical relative path traversal vulnerability in the Advanced Malware Protection (AMP) feature of Cisco Secure Email Gateway. A remote attacker with no account and no credentials can send a single email with a crafted attachment — and end up writing arbitrary files and executing commands as root on the appliance. Cisco's PSIRT became aware of active exploitation in October 2026, and CISA added it to the Known Exploited Vulnerabilities catalog the same day. For the security of cyberspace, the detail that should chill every defender: the box whose job is to stop malicious attachments is the box that gets owned by one.

Summary

Cisco Secure Email Gateway (SEG) is the appliance that filters an organization's email for spam, malware, and other threats before messages reach mailboxes. CVE-2026-76519 is a CWE-23 relative path traversal flaw in how the AMP File Reputation feature handles email attachments. "An attacker could exploit this vulnerability by sending an email that contains a crafted attachment through an affected device," Cisco warned. "A successful exploit could allow the attacker to write arbitrary files and execute commands with root privileges on the underlying operating system."

Nobody needs to open the attachment. Nobody needs to click anything. The gateway itself processes the malicious file during inspection — and that inspection is the exploit. The attacker only needs the ability to send email to an address the appliance scans, which for any internet-facing SEG means literally anyone on the internet.

Cisco found the flaw during its own internal security scanning and published the advisory at 16:00 GMT on October 14. It is the second actively exploited SEG flaw since mid-September (after CVE-2026-76461), suggesting at least one operator is working this product line systematically.

Severity

CVE ID: CVE-2026-76519
CVSS 3.1: 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Attack requirements: None — unauthenticated, remote, low complexity, no user interaction
Impact: Arbitrary file write on the underlying OS, then command execution as root
Exploited in the wild: Yes — Cisco PSIRT aware of active exploitation in October 2026; CISA KEV-listed October 14 with an October 17 federal deadline

The vector is the maximum severity shape: network-accessible, trivially exploitable, zero privileges, full confidentiality/integrity/availability impact. There is no user-interaction gate at all — the "user" in this attack is the security appliance itself.

Affected Versions

Physical and virtual SEG appliances running a vulnerable Cisco AsyncOS release are affected only when both of these conditions hold:

The File Reputation service (part of Cisco AMP) is enabled and assigned to a mail policy — check under Mail Policies > Incoming/Outgoing Mail Policies > Advanced Malware Protection.
Content Scanner Tools is earlier than 25.3.0.5525 — check by running contentscannerstatus at the CLI.

If either condition is false, the attack path does not exist. Not affected: Cisco Secure Email and Web Manager, Cisco Secure Web Appliance, and Cisco Secure Email Cloud (the corrected scanner package is already deployed there). This two-condition gating is genuinely good news for defenders — it means exposure can be determined in about sixty seconds, and many deployments will find they were never reachable.

Technical Analysis

The Cruel Irony: The Filter Is the Vulnerability

Path traversal (CWE-23) is one of the oldest bug classes in security: the application builds a file path from attacker-influenced input — here, names inside a crafted email attachment — without neutralizing relative sequences like ../, so the write lands outside the intended directory. What elevates this from a file-write primitive to root RCE is where the write lands and what runs as root afterward. The AMP scanning pipeline operates with high privilege by design — it must, to dissect hostile files — and CVE-2026-76519 turns that privilege against the appliance: the crafted attachment's path escapes its sandbox, the attacker plants files at chosen locations, and execution follows with root privileges.

As a penetration tester, the lesson I take from this is about trust boundaries around parsers. Every file parser — archive extractors, document renderers, attachment scanners — is an interpreter for untrusted input, and interpreters are where the most dangerous bugs live. The SEG processes attachments from anyone, which makes its AMP pipeline one of the most exposed parsers in the enterprise. Hardening means exactly what Cisco's conditions imply: minimize the attack surface (disable unneeded scanning features), keep scanner components current independently of OS upgrades, and assume the parser will be the entry point.

Computer Viruses Don't Need You to Click Anymore

Computer viruses and email have been paired since the "ILOVEYOU" days — but the classic model always needed the victim to open the attachment. CVE-2026-76519 inverts that model completely: the security infrastructure opens the attachment, and the infrastructure is what gets infected. This is the logical endpoint of a trend defenders have watched for years — from malicious documents exploiting the viewer, to malicious archives exploiting the extractor, to now malicious attachments exploiting the malware filter. The defensive implication is stark: your email security gateway is itself a high-value target, it must be patched with the same urgency as the endpoints it protects, and its compromise gives the attacker a privileged vantage point over all mail flow — the perfect position for interception, and for the kind of quiet, persistent access that precedes larger campaigns.

Why Root on a Mail Gateway Is Worse Than It Sounds

Cisco's advisory contains two warnings that experienced incident responders will read as flashing red lights. First: attackers with root access may remove or hide evidence of exploitation — so on-box logs cannot be trusted, and Cisco advises hunting in network and firewall logs outside the device for suspicious activity like unexpected uploads to external IPs. Second: root compromise may expose the private SSH keys used between cluster members, putting other SEG appliances in the same cluster at risk — a built-in lateral movement path.

For virtual appliances, Cisco's recommendation is telling: rebuild on a fixed release and rotate credentials rather than patching in place. That is the correct call for any appliance that was exposed, because a root-level attacker owns the patching mechanism itself. If your SEG met both vulnerable conditions and faces the internet, treat it as potentially compromised until proven otherwise — not merely unpatched.

Why This Matters

This is the second exploited SEG zero-day in a month, and it shares a shape with the season's other edge-appliance compromises: internet-facing security infrastructure, exploited without credentials, with CISA setting days-not-weeks deadlines. I analyzed the same pattern in CVE-2026-104935 (Ivanti Connect Secure) and CVE-2026-102255 (SonicWall SMA1000) — the lesson repeats because the architecture repeats: the devices we place at the perimeter to protect us are the devices attackers reach first.

What does vulnerable mean in the context of CVE-2026-76519? It means your mail filter — the device you bought to make email safe — can be turned into a root shell by the very attachments it was built to catch, with no login and no click required. How should defenders think about computer viruses in 2026? Not as files that trick users, but as inputs that trick parsers — and the most exposed parser in your estate might be the security appliance itself.

Mitigation

Fastest fix: update Content Scanner Tools to 25.3.0.5525 or later — no software upgrade, no restart required (contentscannerupdate, or automatic updates).
Long-term: migrate to AsyncOS 15.5.5-014 or 16.5.0-780 (releases older than 16.5 should move to 16.5.0-780).
No workaround exists — patching is the only remediation.
Verify exposure in 60 seconds: contentscannerstatus at the CLI for the scanner version; Mail Policies > Advanced Malware Protection for the File Reputation checkbox (incoming and outgoing).
Assume breach if exposed: hunt from October 2026 in firewall/proxy logs for unexpected transfers from the gateway to external IPs; rotate cluster SSH keys and credentials; for virtual appliances, rebuild on a fixed release rather than patching in place.
Reduce the parser's exposure: disable File Reputation on policies that do not need it, and keep scanner components on automatic updates.

References

Cisco security advisory cisco-sa-esa-afw-zqYJkjxp: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-esa-afw-zqYJkjxp
NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-76519
The Hacker News — "Cisco Warns of Active Attacks Exploiting New Critical Secure Email Gateway Vulnerability": http://thehackernews.com/2026/10/cisco-warns-of-active-attacks.html
Help Net Security — CISA KEV additions: https://www.helpnetsecurity.com/2026/10/15/cve-2026-0322-cve-2026-76519-cve-2026-105133-cve-2026-105134-exploted/

More from this blog: about Faizan Akhtar.

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-105134: Ahsay AhsayCBS OS Command Injection RCE Vulnerability — Analysis & Mitigation

Faizan Akhtar — Fri, 16 Oct 2026 01:47:01 +0000

On October 4, 2026, two CVE identifiers were published against Ahsay AhsayCBS, the server-side backup management platform of the Ahsay Cloud Backup Suite: CVE-2026-105134, an OS command injection flaw rated CVSS 10.0, chained with CVE-2026-105133, an authentication bypass. Within three days, attackers were exploiting the chain in the wild — dropping webshells, stealing credentials, and installing cryptominers on backup servers. For the security of cyberspace, few targets are more consequential than the machines that hold everyone's last good copy.

Summary

AhsayCBS is the central server that receives, stores, and manages backups for client machines — widely deployed by managed service providers (MSPs) who run backups for many customer organizations at once. Its management web service is frequently reachable from the internet by design, so administrators can reach it remotely.

Attackers chain two flaws, both reachable by manipulating a single random API argument, with no account and no user interaction. CVE-2026-105133 (improper authentication, CWE-287) sits in the checkSysPwd function of the API component (ApiStructsAction.java) and lets a remote attacker bypass authentication. CVE-2026-105134 (OS command injection, CWE-77/CWE-78) sits in the Replication Receiver component — the endpoint /rps/api/json/UpdateReceivers.do — and turns attacker-controlled text into operating-system commands. Together: unauthenticated remote code execution on the backup server, with the service running as NT AUTHORITY\SYSTEM.

The timeline is brutal. NVD publication: October 4. Huntress observed exploitation beginning October 7 at 23:20 UTC — three days later — with at least five organizations targeted by October 8. Bitdefender's MDR team investigated three separate customer incidents through this chain. Ahsay released hotfixes on October 12, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 14, with a federal remediation deadline of October 17.

Severity

CVE ID: CVE-2026-105134 (chained with CVE-2026-105133)
CVSS 3.1: 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) — CVE-2026-105133: 7.3 High
CVSS 4.0: 9.3 Critical — CVE-2026-105133: 5.5 Medium
Attack requirements: None — unauthenticated, remote, low complexity, no user interaction; public exploit exists; CISA rates exploitation automatable
Impact: Remote code execution as SYSTEM on the backup server
Exploited in the wild: Yes — confirmed by Huntress and Bitdefender MDR since October 7; CISA KEV-listed

The 10.0 vector is the maximum CVSS 3.1 can express: network-reachable, trivial to exploit, no privileges, and the scope change (S:C) means compromise escapes the vulnerable component itself. A public exploit exists, so this is not a theoretical rating — it is a weaponized one.

Affected Versions

Every AhsayCBS server from v7 through v10 reachable by an attacker is exposed unless it runs v10.3.4.45 or later (v10 branch) or v9.15.2.70 or later (v7, v8, v9). Read that carefully, because the patch story here is a trap: Ahsay's earlier patches — v10.3.4.0 and v9.15.2.59 — did not fully fix the flaws, and the NVD entries still list 10.3.4 as unaffected, which the vendor's later advisory supersedes. If you patched early and stopped, you are still vulnerable. The only question that matters is whether the server runs v10.3.4.45 / v9.15.2.70 or later — check the full four-part build number in the web console under System Settings > License > Update License.

Technical Analysis

Pentest Perspective: How the Chain Fits Together

From a pentest standpoint, this chain is a masterclass in why testers chain low and medium findings instead of reporting them in isolation. CVE-2026-105133 alone is "just" an authentication bypass (CVSS 7.3/5.5) — serious, but bounded. CVE-2026-105134 is the command injection that converts access into control. Attackers did exactly what a good penetration tester does: used the auth flaw to reach the injection point, then used the injection to land code execution as SYSTEM.

The shared random argument is the detail that should make every developer pause. Both flaws are reached by manipulating the same parameter — one in the auth check, one in the replication receiver. That pattern screams a single trust boundary drawn in the wrong place: attacker-influenced input flowing into security decisions and into command construction. When I test APIs, a parameter named "random" that influences authentication is an immediate red flag — randomness is for nonces and tokens, never for access decisions, and it must never reach a shell.

What the Attackers Actually Did

Bitdefender MDR's three incident investigations and Huntress's telemetry agree on the playbook. After gaining SYSTEM via the chain, attackers:

Planted JSP webshells in the AhsayCBS web application directories — small scripts that turn ordinary web requests into a command shell.
Staged payloads in C:\Users\Public (writable by every local user) and downloaded tooling via curl and certutil.
Built persistence that survives patching: installing and configuring OpenSSH for a backdoor that does not depend on the vulnerable web service, creating services and scheduled tasks, and elevating accounts.
Deployed XMRig cryptominers disguised as edge.exe (Microsoft Edge's name) with an AI-assisted PowerShell script (Taskgmr.ps1) that kills Windows Task Manager when opened — anti-analysis tradecraft.
Went credential hunting — exactly what you expect on a backup server, which stores credentials for everything it protects.

The cryptominer is the polite outcome. The same webshell and SYSTEM access on an MSP's backup console reaches other people's data — and ransomware operators know that destroying backups comes before encrypting anything. Bitdefender saw no ransomware in its three incidents, but calls continued opportunistic exploitation "near-certain."

What Is Data Integrity When the Backup Server Itself Is Owned?

What is data integrity in the context of CVE-2026-105134? It is the guarantee that your backups are complete, unaltered, and restorable — and this flaw attacks that guarantee at its root. An attacker with SYSTEM on the backup server can silently corrupt, encrypt, or exfiltrate backup sets long before any ransomware note appears. Your disaster-recovery plan assumes the backups are the one thing the attacker cannot touch. This vulnerability breaks that assumption, which is why backup infrastructure deserves the same hardening as domain controllers: isolated networks, no internet exposure of the management interface, and immutable/offline backup copies that no compromised server can rewrite.

Why This Matters

Three lessons stand out. First, patch completeness matters more than patch speed. Admins who applied v10.3.4.0 did the right thing promptly — and remained vulnerable. Verify the build number, not the fact of patching. Second, patching does not evict the attacker. Webshells, rogue services, and OpenSSH backdoors survive the hotfix; every exposed server needs a compromise assessment going back to October 4. Third, several actors are likely using this independently — Bitdefender saw shared infrastructure (C2 at 38.60.252[.]110) but divergent tooling, the signature of a public exploit in wide circulation. A similar chained-auth-to-RCE pattern recently hit the network edge in CVE-2026-104935 (Ivanti Connect Secure), and the unauthenticated-RCE-with-public-exploit shape matches CVE-2026-105192 (LMCache) — both analyzed on this blog.

What is data integrity worth if the system guarding it can be owned remotely with no credentials? That is the question CVE-2026-105134 forces every MSP and backup administrator to answer this week. What does vulnerable mean for a backup platform? It means the last line of defense has become the first target.

Mitigation

Patch to the real fixed builds: v10.3.4.45+ (v10) or v9.15.2.70+ (v7–v9), then reboot as Ahsay's advisory instructs. Earlier builds are not fixed — verify the full version number.
Assume breach on any internet-exposed server and hunt from October 4 onward: unknown JSP/script files in AhsayCBS directories, PowerShell or shells spawned by the AhsayCBS service, .cmd files in C:\Users\Public, unexpected OpenSSH installations, new services/scheduled tasks, privilege changes, and outbound connections to unknown IPs.
Reduce exposure: restrict the management web service to known administrative networks; it should never face the open internet.
Protect data integrity directly: maintain offline/immutable backup copies isolated from the backup server, so a compromised console cannot destroy your recovery path.
Rotate credentials stored on or reachable from the backup server — attackers explicitly hunted them.

References

Bitdefender technical advisory — exploitation chain analysis: https://www.bitdefender.com/en-gb/blog/businessinsights/technical-advisory-ahsaycbs-exploitation-chain-cve-2026-105133-cve-2026-105134
The Hacker News — attackers exploit AhsayCBS flaws to deploy miners: http://thehackernews.com/2026/10/attackers-exploit-ahsaycbs-flaws-to.html
SecurityAffairs — CISA KEV additions (AhsayCBS, Cisco, Palo Alto): https://securityaffairs.com/201041/security/u-s-cisa-adds-palo-alto-networks-pan-os-ahsay-ahsaycbs-and-cisco-secure-email-gateway-flaws-to-its-known-exploited-vulnerabilities-catalog.html

More from this blog: about Faizan Akhtar.

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-105445: Docker Hub Personal Access Token Impersonation Vulnerability — Analysis & Mitigation

Faizan Akhtar — Fri, 16 Oct 2026 01:45:59 +0000

On October 12, 2026, Docker disclosed CVE-2026-105445, a critical vulnerability in Docker Hub that let an attacker impersonate another user at the container registry level using only a personal access token created on their own account. Dubbed "GhostPat" by the researchers who found it, the flaw lived in the account-to-organization conversion flow for over two years — and it is a textbook identity access management failure: the system changed who a token belonged to without changing the secret that proved ownership.

Summary

Docker Hub is the world's largest container image registry. A personal access token (PAT) there acts as a password substitute: CI/CD pipelines and automation tools use PATs to pull, push, or delete images. CVE-2026-105445 broke the binding between a token and its owner. When a user converted a personal account into an organization — a flow requiring them to name an existing user as the new organization's owner — Docker Hub silently reassigned that account's PATs to the new owner. The ownership record changed, but the token secret never rotated, and the new "owner" was never asked for consent or notified.

The abuse is brutally simple: create an account, generate a PAT, convert the account into an organization, name your target as owner. You keep the original secret — and it now authenticates to the registry as the target. Within the token's scope, the attacker could pull, push, or delete images in the target's repositories and in any organization the target could access — including publishing malicious images under a legitimate name.

Introduced August 26, 2024, reported September 30, 2026 by Peter Molnar and Krisztian Hozak (mptrdev.com), fixed by Docker in under four hours. Advisory: October 12. CVE record (CVSS 4.0 9.4): October 13.

Severity

CVE ID: CVE-2026-105445
CVSS 4.0: 9.4 (Critical)
Attack requirements: Only a free Docker Hub account — remote, low complexity, no privileges on the target, no action needed from the victim
Impact: Full registry-level impersonation within the token's scope — pull, push, delete as the target
Exploited in the wild: Docker reviewed every account conversion since introduction (~304,000 pushes) and found no evidence of exploitation

The 9.4 reflects remotely exploitable, low-complexity compromise with high integrity impact: the attacker writes data the ecosystem trusts as the victim's. Docker rated it critical for the software supply chain risk — a poisoned image published under a legitimate name flows into thousands of automated deployments.

Affected Versions

This was server-side in Docker Hub itself — no version to check, no patch to install. Exposure window: August 26, 2024 – September 30, 2026. Only accounts that received transferred tokens during a conversion were affected. Docker emailed them on October 2, 2026 and deactivated the transferred tokens on October 8 (unless owners asked to keep them). Docker's guidance: no email, no action needed.

Technical Analysis

How the Attack Worked

Token creation. Attacker creates a Docker Hub account, generates a PAT with registry scope, keeps the secret.
Conversion. Attacker converts the account into an organization, naming the target as owner.
Silent reassignment. Docker Hub moves the token's ownership record to the target — no secret rotation, no revocation, no consent, no notification.
Impersonation. The attacker authenticates with the retained secret; the token now operates as the target.

The victim experiences nothing — no email, no consent screen, no visible account change. Checking your own settings would never reveal that someone else holds a live credential bound to your identity.

The Bug Class: Bearer Credentials Treated as Transferable Assets

As a penetration tester, this is the seam I hunt for: two correct-looking behaviors combining into a broken one. Tokens are bearer credentials — whoever presents the secret is authenticated. Account conversion transfers assets to a new owner. The flaw was treating a bearer credential as a transferable asset: like changing the name on a house deed while the old owner keeps a copy of the key.

The secure design is standard — rotate or revoke credentials on any ownership change — and Docker has now implemented it, along with the second missing control: an audit signal. Security-relevant state changes must always produce a user-visible event. Docker now requires consent before a user can be named an organization owner and records token ownership changes in an auditable history. Automated scanners never find business-logic flaws like this; humans asking "what happens if I abuse this flow?" do.

Identity Access Management Failure: Why Token Lifecycle Is Everything

Identity access management means the right identities get the right access — and access dies when the relationship changes. CVE-2026-105445 is IAM failure in pure form: the identity on a credential was rewritten while the access survived. This matters beyond Docker Hub because PATs are the skeleton keys of modern engineering: they live in CI/CD secrets, build scripts, and laptops, often broadly scoped with no expiry. When a platform mishandles token lifecycle, the blast radius is every system trusting the registry. If your pipelines pull base images from Docker Hub — most do — GhostPat-style impersonation is a supply chain injection into your build. I previously analyzed a critical RCE in GitLab CI/CD pipelines — exactly the infrastructure that consumes these images automatically.

Why This Matters for the Security of Cyberspace

The security of cyberspace rests on shared registries — Docker Hub, npm, PyPI — that function as critical infrastructure. One logic flaw in any of them poisons software consumed by millions. Docker's response deserves credit: sub-four-hour fix, full historical review, direct notification, structural changes. But note the honest caveat: for transferred tokens that were never used, registry logs record nothing (logs capture usage, not existence), so those were treated as potentially affected on principle. "No evidence of exploitation" is bounded by what logs can see — which is why digest pinning and image signing (Docker Content Trust, Sigstore) are not optional hardening but the real last line of defense when the registry itself breaks. A related identity-spoofing flaw at the network edge: my analysis of CVE-2026-104935, the Ivanti Connect Secure authentication bypass.

What does vulnerable mean in the context of CVE-2026-105445? It means a trusted platform could silently bind your identity to someone else's credential for two years, with no signal you could ever have seen. How does this affect the security of cyberspace's software supply chain? It proves registries are only as trustworthy as their least-examined account flow — and that provenance verification is the defense that survives even a compromised registry.

Mitigation

Check for Docker's email (October 2, 2026). Received it? Rotate your PATs immediately and review repos and organizations for unexpected pushes, deletions, or digest changes.
No email = no action required — but audit anyway: delete unused PATs, narrow scopes to minimum repositories.
Rotate tokens on any account change: conversions, ownership transfers, team changes.
Pin image digests in production instead of floating tags, so a registry compromise cannot silently swap what you deploy.
Enable image signing and verification (Docker Content Trust / Notary, Sigstore).

Docker's server-side fixes: token transfer removed from conversion, consent now required to name an organization owner, auditable token-ownership history, plus an audit of other credential-transfer flows. Note the advisory's boundary: the flaw never granted Docker Hub web access and could not change passwords, email, or 2FA — registry-level impersonation only. That is precisely why digest pinning and signature verification matter: they protect the layer the platform could not.

References

BleepingComputer — "Docker Hub flaw let attackers impersonate users, tamper with images": https://www.bleepingcomputer.com/news/security/docker-hub-flaw-let-attackers-impersonate-users-tamper-with-images/
The Hacker News — "Docker Fixes Critical Two-Year-Old Hub Flaw": http://thehackernews.com/2026/10/docker-fixes-critical-two-year-old-hub.html
Docker security advisory (mirror): https://daily.dev/posts/docker-hub-security-advisory-cve-2026-105445-ash3twcdv
SC Media brief: https://www.scworld.com/brief/docker-hub-critical-vulnerability-allowed-token-misuse

More from this blog: about Faizan Akhtar.

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-96119: IBM i HTTP Server Administration Code Injection Vulnerability — Analysis & Mitigation

Faizan Akhtar — Thu, 15 Oct 2026 01:46:06 +0000

Summary

On October 13, 2026, IBM disclosed CVE-2026-96119, a critical code-injection vulnerability in the HTTP Server Administration web application on IBM i versions 7.3, 7.4, 7.5, and 7.6. A remote authenticated attacker can exploit improper data sanitization to obtain sensitive information or execute arbitrary code on the system. The flaw carries a CVSS score of 9.9 out of 10. For the broader security of cyberspace, IBM i (formerly AS/400, iSeries) deserves more attention than it gets: these systems quietly run core banking, insurance, manufacturing, and retail workloads worldwide, often for decades, and they are rarely the first systems in the patch queue — which is exactly what makes a 9.9 on this platform so dangerous.

The vulnerability is classified as CWE-94 (code injection): the HTTP Server Administration application fails to properly sanitize data it processes, allowing a remote authenticated attacker to inject code that the server then executes. The stated impact covers both information disclosure (reading sensitive data off the system) and arbitrary code execution (running the attacker's code). IBM i systems concentrate enormous privilege — a single partition may host the database, the application logic, and the web tier — so code execution on one of these machines can mean the entire business workload.

No public proof-of-concept has been confirmed, and IBM's disclosure is the authoritative source for the fix. Given how IBM i environments are typically managed — long maintenance windows, change-control boards, quarterly IPLs — the practical advice is to start the patch process now rather than waiting for the next scheduled window.

Severity

CVE ID: CVE-2026-96119
Title: IBM i (7.3–7.6) HTTP Server Administration — improper data sanitization (CWE-94) leading to information disclosure or arbitrary code execution
CVSS 3.1: 9.9 (Critical) — network attack vector, low complexity, low privileges required, no user interaction; high impact on confidentiality, integrity, and availability
Attack requirements: Remote authenticated attacker — valid credentials on the system with access to the HTTP Server Administration application; no victim interaction needed
Weakness: CWE-94 — Improper Control of Generation of Code (code injection)
Exploitation status: No confirmed public PoC at disclosure; independent EPSS modeling places near-term exploitation probability low — but IBM i flaws attract targeted, quiet exploitation against high-value tenants

Affected Versions

IBM confirms the following releases are affected:

IBM i 7.3
IBM i 7.4
IBM i 7.5
IBM i 7.6

The vulnerable component is the HTTP Server Administration web application (the IBM HTTP Server for i admin interface). IBM's PSIRT advisory provides the PTF (Program Temporary Fix) numbers for each release — apply the PTF for your exact release and technology refresh level. Note that IBM i 7.3 is an older release; if you are still running it, this CVE is another argument for accelerating your upgrade planning.

Technical Analysis

Code injection through improper sanitization follows a pattern every security researcher recognizes: user-controlled input reaches a place where it is interpreted as code, and the sanitization layer that should have neutralized it is either absent or bypassable. In a web administration application, the attack surface is the set of inputs the admin UI accepts — form fields, configuration parameters, file paths, hostnames, directives — and the question is always which of those inputs the backend passes to an interpreter, a shell, or a template engine without sufficient scrubbing.

On IBM i, the stakes of that mistake are amplified by the platform's architecture. IBM i is famous for its single-level storage and the deep integration between the operating system, the Db2 database, and the application runtime. Objects on the system carry authority with them, and a job running with sufficient authority can reach across what would be hard boundaries on other platforms. Arbitrary code execution in a privileged server job on IBM i is therefore not just "a shell on a box" — it can be a direct path to the database libraries holding customer accounts, balances, and personal data.

Attack Scenario: From a Login to the Database

Structured the way a pentest report would present it:

Initial access: The attacker authenticates to the HTTP Server Administration web application. IBM i shops often have many user profiles, shared service accounts, and — critically — default or weak passwords on non-production profiles that also exist in production. Any valid authenticated session with access to the admin app is the starting point.
Injection: The attacker submits crafted input through the admin interface — data the application fails to sanitize — which the backend interprets as executable code.
Execution and disclosure: The injected code runs in the context of the HTTP server job. Depending on that job's authority, the attacker can read sensitive files and database objects or execute arbitrary commands.
Impact: Information disclosure gives the attacker the data itself; code execution gives them the system. On a platform hosting core business workloads, either outcome is severe — and the two together are the 9.9.

The "remote authenticated" requirement is the one control standing between the internet and this flaw. That makes credential hygiene on IBM i — a platform where password policies are sometimes treated as optional — the decisive defensive factor alongside patching.

What Is Data Integrity — and Why This CVE Threatens It

A useful question here: what is data integrity, and why does it matter for this vulnerability? Data integrity means your data is accurate, consistent, and unaltered except by authorized processes. Most people think of breaches as stealing data, but the scarier failure is changing it. An attacker with arbitrary code execution on an IBM i partition hosting a core banking or ERP workload can modify balances, alter transaction records, or tamper with audit logs — and the victim may continue operating on corrupted data for weeks before noticing. Confidentiality breaches make headlines; integrity breaches destroy the trust a business runs on. This is why the "high integrity impact" in the CVSS rating deserves as much attention as the headline code-execution capability.

The IBM i Patch-Reality Problem

There is a cultural dimension to IBM i security that makes CVE-2026-96119 worse than its CVSS twin on a Linux web server. IBM i systems are managed for stability over speed: changes go through formal change control, PTFs are applied in maintenance windows, and "if it ain't broke" is practically a design philosophy. Attackers know this. A critical flaw on a platform with slow patch cycles has a longer useful life than the same flaw on a platform patched weekly. The fix exists — IBM published PTFs — but the window between disclosure and the next maintenance IPL is the attacker's opportunity. Emergency change requests exist for exactly this situation; a 9.9 with network reachability qualifies.

FAQ: Key Questions on CVE-2026-96119

What is data integrity risk from CVE-2026-96119 in one sentence? An attacker who can execute arbitrary code on your IBM i partition can silently alter the business data the system exists to protect — balances, records, logs — which is why integrity impact, not just data theft, should drive your patch priority.

Does the attacker need to be on the internal network? The flaw is remotely exploitable over the network by an authenticated attacker. If the HTTP Server Administration interface is reachable from untrusted networks — or from a compromised workstation inside the network — the attack path exists. Restrict the admin interface to management networks as a matter of policy.

We run IBM i 7.3 — are we affected? Yes, 7.3 through 7.6 are all listed as affected. And 7.3's age means you should treat this CVE as two tasks: apply the PTF now, and put the release upgrade on the roadmap — a pattern I have flagged before for aging infrastructure, including the end-of-life firmware issues in ASUS router firmware (CVE-2026-19386) and the unpatched deserialization flaw in LMCache (CVE-2026-105192).

Why This Matters

IBM i is the invisible backbone of industries that cannot afford downtime: banks settle transactions on it, insurers price policies on it, manufacturers run shop floors through it. These systems are rarely internet-famous, which is precisely why they are attractive — the security community's attention, and therefore its defensive tooling and threat intelligence, concentrates elsewhere. A 9.9 code-injection flaw in the platform's own web administration interface is the kind of vulnerability that red teams dream about and blue teams discover during incident response.

There is also a workforce dimension. The IBM i administrator population is aging, and deep platform expertise is getting harder to hire. Security guidance that assumes a well-staffed, modern SecOps team does not match the reality of many IBM i shops — which is why the mitigation section below emphasizes the few high-leverage actions (patch, restrict the admin interface, audit profiles) that a small team can actually execute.

For more on my background and research focus, see the About page.

Mitigation

Apply IBM's PTFs immediately: Install the Program Temporary Fix for CVE-2026-96119 matching your exact IBM i release (7.3–7.6) and TR level. If your change process cannot accommodate an emergency PTF, escalate — a 9.9 is the textbook justification for one.
Restrict the admin interface: The HTTP Server Administration application should be reachable only from management networks or via VPN — never from the general user LAN and never from the internet. Network-level restriction buys time even before the PTF is applied.
Audit user profiles: Review profiles with access to the HTTP Server Administration app. Disable default profiles, remove *ALLOBJ where it is not needed, and enforce password policies — the attack requires authentication, so every unnecessary credential is unnecessary risk.
Monitor for exploitation: Review HTTP server access logs and the system audit journal (QAUDJRN) for unusual admin-interface activity, unexpected job starts under the HTTP server user, or unfamiliar objects appearing in system libraries.
Verify data integrity after patching: Because this flaw enables silent data modification, consider a reconciliation pass over critical business data (balances, master records) against backups or external statements for the exposure window.

References

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-75732: Adobe Experience Manager Incorrect Authorization RCE Vulnerability — Analysis & Mitigation

Faizan Akhtar — Thu, 15 Oct 2026 01:44:59 +0000

Summary

On October 13, 2026, Adobe published security updates for CVE-2026-75732, a critical incorrect-authorization vulnerability in Adobe Experience Manager (AEM) that can lead to arbitrary code execution in the context of the current user. The flaw carries a CVSS score of 9.9 out of 10, requires no user interaction to exploit, and — critically — the CVSS scope is marked as changed, meaning the impact escapes the vulnerable component itself. In the wider security of cyberspace, content-management platforms like AEM are high-value targets because they sit at the intersection of the public website and the corporate network: compromise the CMS and you can deface the brand, steal customer sessions, or pivot deeper into the enterprise.

Adobe's advisory describes the issue as an incorrect authorization vulnerability (CWE-863). In plain terms: the application fails to properly enforce who is allowed to do what, and an attacker can perform actions — or reach functionality — that should be off-limits. When that enforcement failure exists in a component capable of executing code, the result is arbitrary code execution with the potential to elevate access or take over the victim's account or session.

The "no user interaction" detail deserves emphasis. Many web vulnerabilities need a victim to click a link or open a file; this one does not. The attacker interacts directly with the vulnerable AEM instance. Organizations running AEM — especially internet-facing author or publish instances — should treat this as a patch-now event.

What Does "Vulnerable" Mean in the Context of CVE-2026-75732?

To answer what does vulnerable mean here: an AEM installation is vulnerable if it runs an affected version without Adobe's October 2026 update, because the authorization checks guarding a code-execution path can be bypassed. You cannot detect this exposure by looking at logs for "weird logins" — the flaw is in the application's own permission logic, so the fix must come from the vendor patch, verified by checking your AEM version against Adobe's security bulletin.

Severity

CVE ID: CVE-2026-75732
Title: Adobe Experience Manager — incorrect authorization (CWE-863) leading to arbitrary code execution
CVSS 3.1: 9.9 (Critical) — network attack vector, low complexity, low privileges required, no user interaction; scope changed; high impact on confidentiality, integrity, and availability
Attack requirements: None on the victim side — no user interaction; attacker interacts directly with the vulnerable AEM instance over the network
Weakness: CWE-863 — Incorrect Authorization
Exploitation status: No confirmed public PoC at disclosure; Adobe's severity rating and the "scope changed" marker warrant immediate patching regardless

Affected Versions

Adobe's security bulletin for October 2026 lists the affected Adobe Experience Manager releases and their fixed counterparts. Administrators should consult the official Adobe bulletin (helpx.adobe.com/security) for the exact version mapping, as AEM ships in multiple forms — AEM as a Cloud Service, AEM 6.5.x on-premise, and AEM Sites/Forms/Assets deployments — and the fix differs by line.

If you are unsure whether you are affected: any internet-facing AEM author or publish instance that has not applied Adobe's October 2026 security update should be treated as exposed. Cloud Service customers should verify their environment has received the latest release; on-premise teams must apply the service pack or cumulative fix pack named in the bulletin.

Technical Analysis

Incorrect authorization is a deceptively boring name for a devastating bug class. The idea is simple: software is supposed to check "is this user allowed to perform this action on this object?" before doing it. When that check is missing, wrong, or applied to the wrong object, the application's own permission model becomes fiction. An attacker does not need to steal credentials or find a password — they simply ask the application to do something it should refuse, and the application complies.

What elevates CVE-2026-75732 from a privilege problem to a 9.9 is the destination of the broken check: a code-execution path. Adobe states the flaw can result in arbitrary code execution in the context of the current user, with the potential to gain elevated access or control over the victim's account or session. And because the CVSS scope is changed, the security impact is not confined to the vulnerable component — the attacker can affect resources beyond the component's own authority. In practical terms, that is the difference between "the attacker can run code inside one AEM bundle" and "the attacker can reach the wider system."

Attack Scenario: Walking Through an Open Gate

Mapped the way a pentest team would scope it:

Reconnaissance: The attacker identifies an internet-facing AEM instance (publish instances are the usual exposure; author instances should never be public, but misconfigurations happen).
Authorization bypass: The attacker crafts requests that reach functionality or resources the application's permission model should deny — the incorrect-authorization flaw fails to stop them.
Code execution: Through the improperly authorized path, the attacker triggers execution of arbitrary code in the context of the current user.
Escalation and persistence: With scope changed, the attacker works toward elevated access, session takeover, or persistence — and from a compromised CMS, the natural next targets are the web content itself (defacement, malicious script injection into pages served to visitors) and lateral movement into connected systems.

Note what is absent from this chain: no phishing, no malware delivery to a victim, no stolen password. The attacker's only prerequisites are network reachability to the AEM instance and knowledge of the bypass — which is exactly why "no user interaction" vulnerabilities in public-facing software are patched first and asked about later.

Identity Access Management: When the Application Forgets to Ask

This flaw is fundamentally an identity access management failure at the application layer. IAM is usually discussed in terms of users, roles, and single sign-on — but its deepest layer is the authorization check inside the code: "this request, from this principal, for this resource — allowed or denied?" CVE-2026-75732 shows what happens when that innermost check is wrong. External IAM controls (WAF rules, network segmentation, strong admin passwords) still matter, but they cannot fully compensate for an application that authorizes its own attacker. Defense in depth means fixing the broken check and keeping the compensating controls.

For AEM operators, there is a second IAM lesson: publish instances should serve content with minimal privilege, author instances should sit behind VPN or private networking, and service accounts used by AEM integrations should follow least privilege. A code-execution flaw hurts far less when the compromised context has nowhere interesting to go.

Why "Scope Changed" Should Worry You

CVSS scope is one of the most under-read fields in vulnerability management. "Unchanged" means the damage stays inside the vulnerable component; "changed" means the attacker can break out of it. For a CMS, scope-changed code execution is the scenario where the compromise stops being "someone can run code in the CMS" and becomes "someone can affect the host, the sessions of legitimate users, or connected services." When triaging, treat scope-changed 9.9s as the top of the queue — above even other criticals with unchanged scope.

FAQ: Key Questions on CVE-2026-75732

What does vulnerable mean for an Adobe Experience Manager deployment? It means the AEM version you run still contains the broken authorization logic — the application will grant a crafted request access it should deny. The only reliable test is version verification against Adobe's October 2026 bulletin; log review alone cannot prove you are safe.

Does the attacker need a victim to click anything? No. Adobe's advisory states exploitation does not require user interaction. The attacker targets the AEM server directly, which is why internet-facing publish instances are the highest-priority patch targets.

How does this compare to other CMS authorization flaws? The pattern will be familiar to anyone who has followed CMS security: a permission check that fails open, chained into code execution. I have analyzed the same shape before in different stacks — for example, the pre-authentication request-forgery chain in SonicWall SMA (CVE-2026-102255) and the authentication bypass in Ivanti Connect Secure (CVE-2026-104935) — where the missing or broken check was the entire vulnerability.

Why This Matters

AEM powers the public websites of banks, governments, retailers, and media companies. A compromised CMS is not just a server problem — it is a trust problem. Attackers who control the publishing pipeline can inject skimmers into checkout pages, replace downloads with malware, or publish disinformation under a trusted brand. The blast radius of a CMS compromise is measured in the audience of the website, not the size of the server fleet.

This is also a reminder about where the security of cyberspace actually gets decided: not in dramatic zero-day headlines, but in whether organizations patch their content platforms within days instead of quarters. AEM instances have a habit of becoming "set and forget" infrastructure — deployed by an agency, rarely touched afterward. If that describes your AEM footprint, this CVE is your wake-up call to inventory every instance first and patch second.

For more on my background and research focus, see the About page.

Mitigation

Patch immediately: Apply Adobe's October 2026 security update for CVE-2026-75732. Cloud Service environments should confirm the latest release is active; on-premise AEM 6.5.x must be updated to the fixed service pack / cumulative fix pack named in the bulletin.
Reduce exposure: Ensure AEM author instances are not reachable from the internet — they belong behind a VPN or private network. Publish instances should sit behind a WAF with AEM-specific rules.
Least privilege: Review AEM user accounts, service users, and integration credentials. Remove unused accounts and trim permissions — this is the identity access management control that limits the damage if the authorization flaw is exploited before you patch.
Hunt for exploitation: Review AEM access and error logs for unusual requests to administrative or code-execution-adjacent endpoints, especially from unfamiliar IPs. Look for unexpected content modifications, new users, or unfamiliar OSGi bundle activity.
Content integrity check: After patching, verify the integrity of published content — compare against known-good versions. A CMS compromise can leave behind malicious page modifications that survive the patch.

References

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-89107: SAP S/4HANA Code Injection Remote Code Execution Vulnerability — Analysis & Mitigation

Faizan Akhtar — Thu, 15 Oct 2026 01:43:30 +0000

Summary

On October 13, 2026, SAP published security updates for CVE-2026-89107, a critical code-injection vulnerability in SAP S/4HANA (Manage Substitution/Validation Rules) that lets an authenticated attacker with specific business privileges execute arbitrary ABAP code on the system. The flaw carries a CVSS score of 9.9 out of 10 — about as high as severity gets. In the broader security of cyberspace, ERP systems like S/4HANA are crown-jewel targets: they hold a company's financial records, payroll, procurement, and master data. A code-injection flaw there is not just an IT incident — it is a direct path to compromising the financial truth of an entire enterprise.

The vulnerability is deceptively simple in structure. The "Manage Substitution/Validation Rules" functionality lets finance and controlling users define business rules using a domain-specific scripting language — small snippets of logic that decide, for example, which general-ledger account a document posts to. SAP's disclosure states that this rule-definition functionality does not sufficiently validate the input it processes. An attacker with the right business privileges can submit specially crafted input that escapes the scripting language and is interpreted as executable ABAP code by the rule-processing logic. Successful exploitation can lead to full compromise of the affected system, with high impact on the confidentiality, integrity, and availability of the system.

No public proof-of-concept exploit has been confirmed at the time of writing, and the flaw is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. But that should comfort no one: authenticated code-injection bugs in widely deployed ERP platforms are exactly the kind of weakness that gets weaponized quietly, and the October 2026 SAP Security Patch Day guidance is unambiguous — apply the patches and lock down the affected functionality.

What Does "Vulnerable" Mean in the Context of CVE-2026-89107?

A common question — what does vulnerable mean here, in practical terms? It means that a legitimate, working business feature (rule definition) doubles as an attack surface. The system is vulnerable not because of a missing patch on some obscure service, but because user-controlled input flows into an interpreter without enough validation. Any S/4HANA installation where users can access the Manage Substitution/Validation Rules apps is potentially exposed until the patch is applied.

Severity

CVE ID: CVE-2026-89107
Title: SAP S/4HANA (Manage Substitution/Validation Rules) — code injection (CWE-94) leading to remote execution of arbitrary ABAP code
CVSS 3.1: 9.9 (Critical) — network attack vector, low complexity, requires low privileges and no user interaction; total loss of confidentiality, integrity, and availability
Attack requirements: Authenticated access with specific business privileges (e.g., a finance-role user); no user interaction needed beyond the attacker's own session
Weakness: CWE-94 — Improper Control of Generation of Code (code injection)
Exploitation status: No confirmed public PoC or active exploitation reported at disclosure; not currently in the CISA KEV catalog — patch proactively

Affected Versions

SAP's disclosure identifies SAP S/4HANA systems with the "Manage Substitution/Validation Rules" functionality as affected. This covers the Fiori-based apps used to create and maintain substitution and validation rules for financial documents (the modern successors to the classic GGB1/OB28/OBBH customizing transactions in FI). SAP addressed the flaw in its October 2026 Security Patch Day — administrators should consult the SAP Security Notes released that day for the exact note covering CVE-2026-89107 and the precise product-version mapping.

If you are unsure whether you are affected: if your S/4HANA landscape includes the Manage Substitution/Validation Rules Fiori apps and grants business users access to them, treat the system as affected until you confirm the October 2026 patch level is applied.

Technical Analysis

Code injection (CWE-94) is one of the oldest vulnerability classes in software, and it keeps reappearing in new clothes. The pattern is always the same: an application accepts input that is meant to be data or a constrained script, but somewhere along the processing chain the input is handed to a real interpreter without being confined to the intended language. SQL injection, command injection, and template injection are all siblings of this bug. Here, the sibling is ABAP code injection — and it is a particularly dangerous one, because ABAP is not a sandboxed toy language. It is the full programming language of the SAP application server, with access to the database layer, the operating system interfaces the server exposes, and the entire business-logic API surface.

Consider how the vulnerable feature works from the attacker's perspective. Substitution and validation rules are legitimate business logic: "when a document of type X posts to company code Y, substitute cost center A with cost center B." The rule-definition UI exposes a small expression language so that business users can write conditions without calling a developer. The vulnerability means the boundary between that small expression language and raw ABAP is not enforced. Crafted input containing ABAP statements survives the validation layer and is later compiled or interpreted by the rule engine as genuine code.

Attack Scenario: A Finance-User Account Becomes a System Takeover

Picture the attack chain as a pentest team would map it:

Initial access: The attacker needs an authenticated session with the business privileges required to define substitution or validation rules. In the real world, that could come from a phished finance employee, a compromised service account, or even a low-privilege insider.
Injection: Using the rule-definition interface, the attacker submits a rule whose condition or substitution logic contains embedded ABAP statements — the crafted payload.
Execution: When the rule engine processes the rule (on save, on validation, or when a document triggers the rule), the injected ABAP runs on the application server.
Impact: Arbitrary ABAP code execution can read or modify financial documents, create backdoor users, alter master data, or deploy persistent code — effectively a full compromise of the S/4HANA system and the data it guards.

The key insight is the privilege boundary being crossed: the attack starts with business-level privileges (defining a finance rule — something thousands of users legitimately do) and lands at code execution on the application server. There is no second factor, no extra authorization check between "write a rule" and "run my code," because the rule engine itself is the confused deputy.

Identity Access Management: The Attack Still Needs a Door

One nuance matters for defenders: unlike an unauthenticated network exploit, CVE-2026-89107 requires the attacker to already hold credentials with specific business privileges. This is where identity access management becomes the first line of defense. Overly broad role assignments are the norm in many SAP landscapes — users accumulate authorizations over years of role changes, and "temporary" access becomes permanent. Every finance user who holds rule-definition authorizations they do not actually need is a potential entry point for this vulnerability. Tightening SAP roles is not just good hygiene; for this CVE, it directly shrinks the population of accounts an attacker can weaponize.

It is also worth noting what this flaw is not: it is not phishing-dependent, it needs no victim click, and once the attacker holds the right account, exploitation is deterministic. Patch status and role design are the two controls that matter.

Why ABAP Injection Is Worse Than It Sounds

For readers who do not live in the SAP world, a comparison helps. Injecting SQL into a web app typically gives the attacker the database behind that app. Injecting ABAP into S/4HANA is closer to injecting code into the application server itself: the attacker inherits the trust the server places in its own code — reading data across modules, calling remote-enabled function modules, and in many configurations reaching OS-level interfaces. The CVSS 9.9 reflects exactly this: from one authenticated session, the entire system falls.

FAQ: Key Questions on CVE-2026-89107

What does vulnerable mean for an SAP S/4HANA system facing CVE-2026-89107? It means any system where users can reach the Manage Substitution/Validation Rules functionality without the October 2026 patch is exposed. The vulnerable state is not a misconfiguration you can spot in a dashboard — it is a code-level flaw in how input is validated, so the only reliable fix is the vendor patch plus role review.

Can this vulnerability be exploited without any credentials? No. The attacker must authenticate and hold the specific business privileges needed to define substitution or validation rules. That is precisely why identity access management — reviewing who holds those authorizations — is a meaningful mitigation alongside patching.

Is there a known exploit in the wild for CVE-2026-89107? As of this writing, no public proof-of-concept and no CISA KEV listing. Treat the absence of public exploitation as a head start for patching, not as evidence of safety — high-value ERP flaws attract quiet, targeted exploitation long before public PoCs appear.

Why This Matters

ERP vulnerabilities occupy a special place in the security of cyberspace because of what ERP systems contain. A compromised web server is bad; a compromised S/4HANA system means the attacker can rewrite the financial records a company reports to regulators, investors, and tax authorities. The blast radius extends beyond data theft into data integrity — if attackers can alter posted documents or master data, the victim may not even know which records to trust afterward.

There is also a supply-chain dimension. S/4HANA systems at large enterprises connect to banks, suppliers, and government tax portals. A foothold in the ERP is a launchpad into business-partner ecosystems. Defenders who track CVEs by "would this let an attacker touch money or the books" should rank CVE-2026-89107 near the top of their patch queue — similar in spirit to other critical ERP flaws, such as the unauthenticated RCE chain I analyzed in GitLab's CI/CD pipeline (CVE-2026-97229) and the deserialization-driven takeover in LMCache's AI serving layer (CVE-2026-105192), where attacker-controlled input reaching an interpreter meant total compromise.

For more on my background and research focus, see the About page.

Mitigation

Patch immediately: Apply the SAP Security Note for CVE-2026-89107 from the October 2026 Security Patch Day across all S/4HANA systems (development, QA, and production). Verify the patch level with your basis team before closing the ticket.
Restrict rule-definition access: Audit which users and roles can access the Manage Substitution/Validation Rules apps (and the classic GGB1/OB28/OBBH transactions). Remove the authorization from anyone who does not actively maintain financial rules — this is the core identity access management control for this CVE.
Review existing rules: Treat every substitution and validation rule as potentially tampered with. Have a functional consultant review rule definitions created or modified recently for suspicious expressions or embedded code.
Monitor for exploitation: Check application logs, ST22 short dumps, and SM21 system logs for unusual rule-engine errors or unexpected program executions around the time of rule changes. Unusual background jobs or new users created by dialog users with finance roles deserve investigation.
Segregate duties: Enforce segregation of duties so that the same user cannot both define financial rules and post the documents those rules affect — this limits what a single compromised account can achieve even before patching.

References

Report by Faizan Akhtar — The Cyber Security Researcher

CVE-2026-105192: LMCache (vLLM KV-Cache) Unauthenticated Remote Code Execution Vulnerability — Analysis & Mitigation

Faizan Akhtar — Wed, 14 Oct 2026 18:43:16 +0000

Summary

On October 7, 2026, JFrog Security Research disclosed CVE-2026-105192, a maximum-severity CVSS 9.8 flaw in LMCache — the open-source key-value cache layer bolted onto vLLM large-language-model inference servers — that lets an unauthenticated remote attacker execute arbitrary code on the cache server. The root cause is the oldest trap in application security: unsafe deserialization. In multiprocess (distributed) mode, LMCache opens a network socket with no authentication, no encryption, and no message verification — and any message it receives with a particular extension code is passed straight to Python's pickle.loads() before any handler runs. One crafted network message, and the attacker owns the process. There is no patch. As of disclosure, the LMCache maintainers had not published their own advisory, a public proof of concept was released alongside the JFrog write-up, and the only defenses are configuration changes and interim mitigations. The security of cyberspace increasingly depends on AI infrastructure that was built for research velocity, not adversarial environments — and this flaw is what that gap looks like in practice.

The exposure math is what makes this genuinely scary. LMCache's cache server binds to localhost by default — not remotely reachable. But operators routinely override that with a routable address (via --host) to scale vLLM across multiple nodes, and the project's own example Kubernetes deployment runs with hostNetwork, exposing the service on all interfaces. In those deployment shapes, CVE-2026-105192 is unauthenticated network RCE. And because official LMCache container images run the process as root, exploitation can mean full host-level control — on machines that typically also hold model weights, API keys, and customer prompts.

Severity

CVE ID: CVE-2026-105192
Title: LMCache KV-cache server — unauthenticated remote code execution via unsafe pickle deserialization (CWE-502)
CVSS 3.1: 9.8 (Critical)
Attack requirements: None — unauthenticated, remote (network-reachable in common deployment shapes), low complexity; public PoC available
Weakness: CWE-502 — Deserialization of Untrusted Data
Exploitation status: No confirmed in-the-wild exploitation and not in CISA KEV as of October 13, 2026 — but a public PoC exists and there is no patch, making this a prime pre-weaponization patching story

Affected Versions

LMCache 0.3.9 (October 2025) through 0.5.5 (latest stable)
0.5.6 release candidates and the development branch
Multiprocess (distributed) mode only — single-process deployments that do not expose the standalone cache server are not affected

Fixed version: none exists. No patched release had shipped as of disclosure; LMCache had not published its own security advisory. Treat every multiprocess deployment as vulnerable until a fixed release is announced.

Technical Analysis

The architecture of the flaw is a study in how research-grade infrastructure becomes production infrastructure without acquiring production-grade security. In multiprocess mode, LMCache runs a standalone cache server that the LLM worker processes reach over ZeroMQ. The server opens a ROUTER socket on port 5555 by default — and that socket has no CURVE encryption, no ZAP authentication, and no message verification whatsoever. Anyone who can reach the socket can talk to it, and the server will trust whatever arrives.

Messages arrive encoded as msgpack, and one particular message shape is wired directly to danger: extension code 1 is dispatched to DeviceIPCWrapper.Deserialize, which calls pickle.loads() on the attacker-controlled bytes — before any handler runs. Python's pickle is not a data format; it is a serialization of a tiny virtual machine, and unpickling untrusted bytes is functionally equivalent to executing untrusted code. A single DEALER message to the ROUTER socket therefore executes arbitrary code as the LMCache process user. There is no login to bypass, no session to steal, no second request needed.

What Is Data Integrity — and Why Pickle Breaks It

What is data integrity in this context? It is the guarantee that data arriving over a channel is the data the sender intended — unmodified, untampered, authentic. Deserialization without verification destroys that guarantee by design: the receiver reconstructs objects from bytes it never authenticated, so a tampered message is indistinguishable from a legitimate one. The safe pattern is boring and well-known — use a serializer that cannot execute code (JSON, protobuf, msgpack with a fixed schema) and authenticate the channel (TLS, CURVE, HMAC) so tampering is detectable. LMCache's multiprocess transport skipped both: pickle for the format, and nothing at all for channel integrity. The result is a textbook CWE-502 with a 9.8 score.

From Localhost to the Internet: How Deployment Shapes Create RCE

On paper, the default bind is localhost — not remotely reachable. In practice, the vulnerable population is large, because the whole point of multiprocess mode is multi-node scaling, and multi-node scaling requires a routable address. Operators pass --host with a cluster address; Helm-style deployments and the project's own example Kubernetes manifests run the cache server with hostNetwork, binding it to all interfaces. Each of these is a reasonable operational choice that quietly converts a localhost-only service into unauthenticated network RCE.

The privilege context multiplies the impact. Official LMCache container images run the cache server process as root. So the exploit chain in a typical vulnerable deployment is: one unauthenticated network message → arbitrary code execution → as root → on a host that usually also runs the vLLM workers, with access to model weights, inference API keys, and the prompts users submitted. That last item deserves emphasis: LLM inference servers process other people's data. Compromising the cache layer of a multi-tenant inference deployment is not just a host takeover — it is a data-confidentiality event.

Could a Routine Pentest Catch This?

Pentest teams reading this should treat LMCache as a case study for AI-infrastructure scoping. A routine pen test of an AI deployment that stops at the HTTP API will miss this entirely — the vulnerable socket is a separate ZeroMQ service on port 5555, not the inference endpoint. The checklist that catches it: enumerate all listening services on AI hosts (not just HTTP), fingerprint ZeroMQ/ROUTER sockets, check container processes for root execution, and test whether msgpack/pickle deserialization paths are reachable without authentication. Any AI-infrastructure pentest scope written in 2026 should name the KV-cache layer explicitly — it is now a demonstrated attack surface, not an implementation detail.

FAQ: Key Questions on CVE-2026-105192

What is data integrity, and why does pickle deserialization break it? Data integrity means received bytes are exactly what the legitimate sender produced. Pickle deserialization breaks it because unpickling executes embedded instructions from the byte stream — so a tampered message is not just corrupted data, it is attacker code running inside your process.

Is my LMCache deployment vulnerable if it only listens on localhost? Not remotely — the exploit needs network reachability to the cache server's ZeroMQ socket. But audit this honestly: check for --host overrides, hostNetwork in Kubernetes manifests, and container network modes that expose port 5555 beyond loopback.

What does vulnerable mean in the context of CVE-2026-105192? It means your multiprocess LMCache cache server will execute arbitrary attacker code from a single unauthenticated network message — with no patch available, so only configuration-level mitigations (below) close the hole.

Why This Matters

AI infrastructure is having its "everything is on the network with no auth" era — the same era web infrastructure went through a decade ago, with the same results. LLM inference stacks (vLLM, LMCache, vector databases, agent frameworks) were largely built by researchers optimizing for throughput and iteration speed, then deployed into production, multi-tenant, internet-adjacent environments without a corresponding security hardening pass. The security of cyberspace now partially rests on components like a KV-cache server that opens an unauthenticated pickle endpoint on a network port — and CVE-2026-105192 will not be the last such finding. The GitLab CI/CD regex-compiler RCE (CVE-2026-97229) from two days ago made the same point for DevOps infrastructure: the unglamorous plumbing components are where the critical unauthenticated flaws keep hiding.

The disclosure dynamics here are also worth studying. There is no vendor patch, no vendor advisory, and a public PoC — the worst possible combination for defenders, and the best possible conditions for rapid weaponization. Every day without a fixed release is a day the exploit recipe is public and the fix is not. Organizations running LMCache in multiprocess mode cannot wait for upstream; the interim mitigations below are the patch.

Mitigation

Remove network exposure immediately. Bind the LMCache cache server to localhost only and firewall port 5555 off the network. Keep the service on loopback or a trusted, isolated cluster network. Audit Kubernetes manifests for hostNetwork: true on LMCache workloads and remove it.
Do not run the cache server as root. The official images run as root, which turns RCE into full host compromise. Run the container with a dropped-privilege user (and read-only root filesystem where possible) so a deserialization exploit buys the attacker far less.
Plan the real fix: replace pickle. Per JFrog's interim guidance, the durable remediation is replacing pickle with a safe serializer (JSON, protobuf, or msgpack with a fixed schema) and adding transport authentication — CURVE or HMAC — on the ZeroMQ socket. Track the LMCache repository for the upstream fix and upgrade the moment a patched release ships.
Assume exposure and hunt. With a public PoC and no patch, any multiprocess LMCache instance reachable from untrusted networks should be treated as potentially compromised: review process and network logs for unexpected connections to port 5555, check for unknown processes or persistence on the host, and rotate API keys and credentials that transited the inference environment.
Scope AI infrastructure in security reviews. Add every auxiliary service in the inference stack — cache servers, vector DBs, model registries — to asset inventories, network segmentation policies, and pentest scopes. If a component accepts network input, it is attack surface, no matter how "internal" it was assumed to be.

References

Analysis by Faizan Akhtar, Cyber Security Researcher and Bug Bounty Hunter.

Report by Faizan Akhtar — The Cyber Security Researcher