Apache Traffic Server Fixes 15 CVEs: magick Plugin CVE-2026-111813

Apache Traffic Server (ATS) 9.2.16, 10.1.5 and 10.2.1 fix 15 vulnerabilities, including four scored CVSS 10.0: the experimental magick plugin (CVE-2026-111813), pooled mTLS identity confusion, TLS resumption bypassing per-SNI client certificates, and AWS header signing. Anyone running 9.2.15, 10.1.4, 10.2.0 or older should upgrade. No exploitation is reported and none are in CISA KEV.

ATS is a caching HTTP proxy that sits at the edge of a network, in front of origin servers. The project's own release announcement says it is "used by several large internet services". That position is what makes this batch worth a careful read. Request smuggling, cache poisoning and identity confusion at an edge proxy affect every application behind it, not only the proxy. This post walks through all 15 CVEs, the experimental plugin rated critical at CVSS 10 in its default configuration, how to tell whether your deployment is exposed, and how to patch or mitigate on each platform.

What happened

On Tuesday 20 October 2026, the ATS project tagged and announced three releases: 9.2.16 (the long term support line), 10.1.5 and 10.2.1. A few hours later, at 02:07 UTC on 21 October (20:07 local time for the sender, six hours behind UTC), ATS PMC member Masakazu Kitajo sent a single [SECURITY] message to the announce and users lists titled "Multiple vulnerabilities fixed in Apache Traffic Server 9.2.16, 10.1.5 and 10.2.1". It lists 15 CVEs. The project also published a security page for the release, "October 2026 CVE Release", which groups them as 2 critical, 8 important and 5 moderate by Apache's own rating.

The Apache CVE Numbering Authority published all 15 CVE records later the same day, between 18:20 and 19:20 UTC on 21 October. On Saturday 24 October, the announcement was forwarded to the oss-security mailing list with a short note that it "was posted to the Apache Traffic Server mailing lists a few days ago". That forward is when many downstream packagers and security teams outside the ATS community would have first seen it.

As of 25 October 2026 we found no report of exploitation. The CISA Known Exploited Vulnerabilities catalog (version 2026.10.23, released 23 October at 19:30 UTC, 1,756 entries) contains none of the 15 CVEs and no Apache Traffic Server entry at all. We checked the JSON feed directly.

Timeline

All times are UTC and come from the primary source listed.

When was 10.2.1 actually released?

The ATS downloads page, fetched on 25 October, shows "Traffic Server 10.2.1, Latest Stable, Released August 17, 2026". That date cannot be right for a release that fixes CVEs announced in October. Two primary sources settle it:

• The signed git tag 10.2.1 was created on 20 October 2026 at 22:34:43 UTC (pointing at commit e395e13b). The signed tag 10.2.0 was created on 17 August 2026 at 19:54:26 UTC.
• The [ANNOUNCE] mail for 10.2.1 went out at 00:23:33 UTC on 21 October 2026.

So 10.2.1 shipped on 20 to 21 October, and "August 17, 2026" is the 10.2.0 date left on the page. The 10.2.1 mail has two similar slips: its subject says "Sever" and its body says "the release of Apache Traffic Server 10.2.0". None of this changes what to install, but it matters if your change process compares release dates with advisory dates and rejects 10.2.1 as too old.

How to read Apache's severity labels next to CVSS 10

Three of the four CVSS 10.0 issues are not labelled critical. CVE-2026-111814 and CVE-2026-111815 are "important", and CVE-2026-111812 is "moderate", as are CVE-2026-111809 (CVSS 9.3) and CVE-2026-111811 (CVSS 9.0). Meanwhile CVE-2026-111804 is "critical" at CVSS 8.2.

The October security page explains why: the Apache rating reflects impact "in a default configuration", while CVSS can be higher "for issues that need specific conditions or a non-default configuration to reach." In practice:

• The pooled mTLS issue needs ATS to present client certificates to origins.
• The resumption issue needs sni.yaml hosts with verify_client: STRICT.
• The AWS signing issue needs the origin_server_auth plugin.
• The cache exposure issue needs the experimental tsmemcache plugin.

If a condition is true for you, trust the CVSS number. If none are, the label is closer to right. Triage by configuration, not by label.

Technical details

All values below come from the [SECURITY] announcement, the project's October 2026 security page, and the 15 CVE records on cve.org. CVSS is the v3.1 base score as published by the project. "Affected" is the range stated in the announcement; where the CVE record adds an older 8.x range, that is noted in the next section.

The CWE IDs come from the CVE records. The project's own grouping by type is: 5 denial of service, 4 request smuggling, 3 access control bypass, 1 argument injection, 1 memory safety and 1 spoofing or certificate trust issue.

CVSS vectors as published

For teams that feed scores into their own risk models, these are the v3.1 vectors from the announcement:

Credits as published

The announcement credits: Apache Community, Abraxas Labs and The ASF (CVE-2026-111813); Omkhar Arasaratnam and Apache Community (CVE-2026-111804); Martin van Kervel Smedshammer and Nick Muerdter (CVE-2025-31699); Sebastiano Sartor (CVE-2025-55702); Apache Community and OneZ3r0 (CVE-2026-111816); matrix_cain (YakLang), Alieldeen Khaled Ali, Jesse Yang, Alex Williams (Pellera Technologies), VulnCheck as coordinator, and The ASF (CVE-2026-111805); Khalilov Moe (LeetProtect) and The ASF (CVE-2026-111808); Craig Taylor (CVE-2026-111814); Yonghwa Lee, Xint by Theori (CVE-2026-111815); Apache Community (CVE-2026-111810, CVE-2026-111809, CVE-2026-111811 and CVE-2026-111812); Omkhar Arasaratnam (CVE-2026-111817); and Masaori Koshiba (CVE-2026-112381).

Where the CVE records and the announcement differ

The announcement lists affected versions only for the supported 9.x and 10.x lines. Twelve of the 15 CVE records on cve.org go further and also list the 8.x line: 8.0.0 through 8.1.11 for most, 8.0.1 through 8.1.11 for CVE-2026-111813, and 8.1.11 alone for CVE-2026-111817. No 8.x release is part of this fix. If you still run 8.x anywhere, the records tell you it is affected, and the only path the project offers is moving to 9.2.16 or a 10.x release.

The second difference is CVE-2026-111817. A quick reading of the announcement's headline suggests 9.2.16 fixes all 15. It does not. The announcement's own mitigation line for CVE-2026-111817 says "9.x: no fix is included in 9.2.16; affected only if drop_chunked_trailers is enabled". Trailer dropping is off by default in 9.2.x and on by default in 10.x, so a stock 9.2 deployment is not exposed, while a 9.2 deployment that turned the setting on stays exposed after upgrading to 9.2.16.

What the fix commits say

The changelogs list security fixes by commit title rather than CVE. CHANGELOG-10.1.5 and CHANGELOG-10.2.1 include "magick: require signing key and allowlist convert operators", "Require a matching client certificate for outbound session reuse", "proxy: reject resumed TLS sessions missing a required client cert", "Strip unauthorized x-amz- request headers in origin_server_auth", "tsmemcache: bind to loopback by default and add configurable bind address" and "Reuse an origin connection only after its request body is written", along with fixes for HEAD framing, HTTP/2 length and padding checks, the wasm use-after-free and the @ header log throttle.

CHANGELOG-9.2.16 lists only build and analyzer fixes plus a merge titled "9.2.x release 10-19"; it does not itemise the security commits. Rely on the announcement, not that changelog, for what 9.2.16 fixes.

The magick plugin, CVE-2026-111813, in plain language

The magick plugin (magick.so, source in plugins/experimental/magick) is a transformation plugin. Its README says it "runs a restricted set of ImageMagick's convert operators on images coming from the origin": resize, crop, rotate or strip metadata at the edge, then cache the result.

It takes instructions from a query parameter named magick, which carries URL escaped, base64 encoded arguments for ImageMagick's convert. It is a global plugin, so once loaded it inspects every transaction with an image Content-Type.

The design assumed those instructions would be signed: the plugin can verify an RSA signature (sent in a second parameter, magickSig) using a public key named on its plugin.config line. Before the fix the key was optional, and in the default unsigned configuration the client's query string reached convert unfiltered. The CVE record classifies this as CWE-88, argument injection, and the project scored it 10.0 on CVSS v3.1 and v4.0. We will not go into what those arguments allow. What matters is the fix, which the updated README describes:

• The key is mandatory. The plugin "refuses to load without it".
• The command shape is fixed. The decoded command must be convert mpr:b, then operators, then mpr:a, where those are in-memory registers for the origin image and the result. Anything else returns 403.
• Operators are allowlisted. Eight value-free operators (such as -auto-orient, -strip, -trim) and eighteen single-value operators (such as -resize, -crop, -quality) are allowed. Everything else returns 403, including file writes, @file references, several coders, and text or drawing operators.
• Plus forms are refused. +resize and similar are rejected because the plugin's argument model and ImageMagick's parser disagree on their arity.

Authentication first, then a strict allowlist even for authenticated callers: that is the right shape for any plugin that hands input to a powerful tool.

Is magick even on my servers?

Probably not, but check. Experimental plugins are not built by default. The plugin docs say they are compiled by passing -DBUILD_EXPERIMENTAL_PLUGINS=ON to cmake on 10.x; 9.2.x uses autotools and --enable-experimental-plugins, and magick also needs the Magick++ library at build time. Even when built, it does nothing until plugin.config loads it. Check in this order:

1. Configured? An uncommented magick.so line in plugin.config means exposed.
2. Installed? magick.so in the plugin directory with no config line means one change away.
3. Built? If experimental plugins were not enabled in your build, it cannot be present.

The commands are in "What to do now" below.

How to disable it

If you do not use it:

1. Comment out or delete the magick.so line in plugin.config (for example /etc/trafficserver/plugin.config, or the SYSCONFDIR that traffic_layout info reports).
2. Restart Traffic Server. Treat a restart as required; we found no documentation saying a reload unloads a global plugin.
3. Confirm with a test request carrying a magick parameter: the response should be the untouched origin image.
4. Optionally delete magick.so and rebuild without experimental plugins.

If you use it, upgrade, generate a key pair, add the public key file as the plugin argument, and make your URL generator sign magick and send magickSig. Check every transformation against the allowlist first, since anything outside it, text overlays included, now returns 403. On fixed releases a keyless line means the plugin will not load, so test how your build handles that in staging.

The other 14 CVEs, grouped by what you need to check

Session sharing and client certificates (CVE-2026-111814)

ATS pools origin connections and reuses them across client requests, governed by proxy.config.http.server_session_sharing.match (default both). Some deployments present a client certificate to the origin, and that certificate can be overridden per transaction. The origin authorises a TLS connection on the certificate from the handshake, and reuse performs no new handshake. Before the fix, both did not include the certificate check (the CVE title says the default "omits MASK_CERT"), so a request meant to present certificate B could ride a connection authenticated as A.

The fixed docs for 9.2.x, 10.1.x and latest define both as "Equivalent to host,ip,cert". The cert value compares proxy.config.ssl.client.cert.filename, including per-transaction overrides; certificates chosen through sni.yaml client_cert entries are separated by sni instead. The docs note the cost: more outbound handshakes where client certificates are used, no change where they are not.

TLS resumption across SNI hosts (CVE-2026-111815)

sni.yaml lets you set verify_client per inbound server name: NONE, MODERATE or STRICT. With STRICT, the client must present a certificate. TLS session resumption, through tickets or session IDs, does not re-request a client certificate. Before the fix, a session established under one SNI host without a client certificate could be resumed under another host that required one, skipping the check.

The fixed documentation states the rule now enforced: ATS only resumes a session under the same SNI and verify_client policy that issued it, including the trust anchors in force; otherwise it falls back to a full handshake. It also states that on fixed versions, disabling session tickets with ssl_ticket_enabled "is not required as a workaround". On an unpatched build, turning off tickets for the strict hosts is a reasonable stopgap (see the mitigations below), but it is our suggestion, and session ID caching is a separate resumption path you should also review.

AWS request signing (CVE-2026-111812)

The origin_server_auth plugin signs requests to S3 style origins with the proxy's own credentials. The flaw let a client add AWS request headers that the plugin then signed as if the proxy meant to send them. The CVE record classifies it as CWE-863, incorrect authorisation. The fix commit's title says it all: "Strip unauthorized x-amz- request headers in origin_server_auth". If you use this plugin, the blast radius is whatever the proxy's credentials can do on the bucket, which is a strong argument for scoping those credentials to read only on the specific bucket and prefix the proxy serves.

The shared cache over the network (CVE-2026-111811)

The experimental tsmemcache plugin (source directory plugins/experimental/memcache) exposes the ATS cache through a memcache style protocol. Per the announcement, it allowed "unauthenticated network read, write, and deletion of the shared proxy cache". The fix makes it bind to the loopback interface by default and adds a configurable bind address. A write into a shared cache is the same outcome as cache poisoning: other users get content you did not publish. If you do not know why this plugin is loaded, remove it.

Request smuggling (CVE-2025-31699, CVE-2025-55702, CVE-2026-111816, CVE-2026-111809)

Four issues let two parties disagree about where one HTTP message ends and the next begins. CVE-2025-31699 returned an origin connection to the pool while the origin still expected request body bytes, so the next user's request was read as leftover body. CVE-2025-55702 treated an unread Expect: 100-continue body as a new request, which matters when a front-end proxy shares connections to ATS. CVE-2026-111816 forwarded, and could cache, a malformed 302 response because of a special case for chunked encoding. CVE-2026-111809 allowed smuggling through HEAD requests carrying a body length header; the fix rejects them. No configuration switch removes these risks. Upgrade.

Denial of service (CVE-2026-111805, CVE-2026-111808, CVE-2026-111810, CVE-2026-112381, CVE-2026-111817)

CVE-2026-111805 and CVE-2026-111808 let an HTTP/2 client exhaust an HTTP/1.1 origin's worker pool, through a truncated Content-Length and a DATA frame padding underflow, so the outage lands on your origin. CVE-2026-111810 (one unthrottled log line per stripped internal @ header) and CVE-2026-112381 (a timing dependent null pointer crash in net_write_io) affect only 9.2.15, 10.1.4 and 10.2.0. CVE-2026-111817 stalls chunked passthrough when trailers are dropped, as described above.

The wasm plugin (CVE-2026-111804)

The experimental wasm plugin, 10.x only, had a use-after-free in its transaction-close handler and forwarded guest supplied metric IDs to the internal stats API without validation. The project rates it critical at CVSS 8.2. Like magick, it has to be built and loaded to matter.

Who is affected

The Debian tracker also shows a number of earlier 2026 ATS CVEs as still open for bookworm, so a distribution package can trail upstream by more than one release. We did not check Ubuntu, Fedora or EPEL status for this post; look up the CVE IDs in your distribution's tracker before assuming a package update exists.

What to do now

Work through these in order. Steps 1 to 4 tell you where you stand; steps 5 to 8 fix it.

1. Find every ATS instance and its version

On a host:

# Version of the running binary
traffic_server -V

# Where config and plugins live for this install
traffic_layout info

# Distribution packages
dpkg-query -W -f='${Package} ${Version}\n' trafficserver 2>/dev/null
rpm -q trafficserver 2>/dev/null

In containers, check the image rather than trusting the tag:

docker run --rm --entrypoint traffic_server your-registry/edge-proxy:prod -V

In Kubernetes, list images that look like proxies, then check each one:

kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | sort -u | grep -iE 'traffic|ats|edge|cache'

Anything at 9.2.15 or lower, 10.1.4 or lower, or 10.2.0 needs the upgrade.

2. Check the plugins that decide your exposure

CONF=/etc/trafficserver   # use SYSCONFDIR from traffic_layout info

# Global plugins: magick, wasm and tsmemcache load here
grep -nE 'magick|wasm|memcache' "$CONF/plugin.config"

# Remap plugins: origin_server_auth (and its older name s3_auth)
grep -nE 'origin_server_auth|s3_auth' "$CONF/remap.config" "$CONF"/*.config 2>/dev/null

# Is the magick shared object even installed?
PLUGINDIR=$(traffic_layout info | awk -F': *' '/PLUGINDIR/ {print $2}')
ls -l "$PLUGINDIR" | grep -iE 'magick|wasm|memcache|origin_server_auth|s3_auth'

A line in plugin.config that is not commented out means the plugin is loaded. A .so file on disk with no config line means it is installed but not active.

3. Check the TLS settings that matter for the CVSS 10 issues

# Origin session sharing policy (CVE-2026-111814)
traffic_ctl config get proxy.config.http.server_session_sharing.match

# Do you present client certificates to origins at all?
traffic_ctl config get proxy.config.ssl.client.cert.filename
grep -nE 'client_cert' "$CONF/sni.yaml"

# Do any inbound hosts require client certificates? (CVE-2026-111815)
grep -nE 'verify_client' "$CONF/sni.yaml"

# Session tickets on globally?
traffic_ctl config get proxy.config.ssl.server.session_ticket.enable

If no client certificate is configured toward origins, CVE-2026-111814 has little to work with in your deployment. If no sni.yaml entry uses verify_client: STRICT, CVE-2026-111815 has the same limit.

4. Check trailer dropping and listening sockets

# CVE-2026-111817: 1 means trailers are dropped
traffic_ctl config get proxy.config.http.drop_chunked_trailers

# Anything ATS listens on that you did not expect (for example a tsmemcache port)
sudo ss -ltnp | grep -E 'traffic_server|\[ET_NET'

5. Upgrade

Verify the download before building:

gpg --import KEYS
gpg --verify trafficserver-10.2.1.tar.bz2.asc trafficserver-10.2.1.tar.bz2
sha512sum -c trafficserver-10.2.1.tar.bz2.sha512

Per the release announcements, a major version upgrade requires recompiling custom plugins, and upgrades should preserve the existing cache. A point release within your line is the smallest step. For distribution packages, update when your distribution ships a fix; until then, build upstream or apply step 7.

6. Rebuild images and templates

Every image, VM template or appliance build that bundles ATS needs a rebuild. Pin the version explicitly, rebuild, run proxy tests and redeploy. Deprecate or delete old images so nobody redeploys them.

7. Interim mitigations if you cannot upgrade today

These come from the advisory text, the fixed documentation and the fix commit titles. They reduce exposure; they do not replace the upgrade.

• magick, wasm, tsmemcache: if not needed, remove their lines from plugin.config and restart. Experimental plugins you do not use are pure risk.
• tsmemcache, if needed: block its port at the host firewall and the network edge so only loopback or a known management network can reach it.
• Session sharing with client certificates: set proxy.config.http.server_session_sharing.match explicitly to include cert (for example ip,host,cert), add sni if you select client certificates through sni.yaml client_cert entries, or set it to none for the affected remaps. Expect more origin handshakes. Test before production.
• verify_client STRICT hosts: consider setting ssl_ticket_enabled: 0 on those sni.yaml entries until you upgrade. This is our suggestion for unpatched builds, not a project instruction, and it does not cover every resumption path.
• origin_server_auth: scope the proxy's AWS credentials to read only on the specific bucket and prefix it serves, and strip client supplied x-amz- headers at an earlier layer if your setup allows it.
• Trailer dropping on 9.2.x: if you turned proxy.config.http.drop_chunked_trailers on and do not need it, turn it off.

There is no configuration workaround in the advisory for the request smuggling or HTTP/2 issues.

8. Watch your logs while you patch

After upgrading, watch for spikes in magick 403s (unsigned or out of allowlist requests), sudden diagnostic log growth (CVE-2026-111810) and origin worker pool alerts. magick query parameters arriving at a proxy that never used the plugin deserve a look in access logs, though they do not prove an attempt on their own.

What changed since the first reports

• 10.2.1's date: the downloads page shows the 10.2.0 date; the tag and announcement say 20 to 21 October.
• 9.2.16 and CVE-2026-111817: no fix on 9.2, which is affected only with trailer dropping on.
• 8.x: the CVE records list it for 12 of 15 CVEs; the announcement does not, and there is no 8.x fix.
• Reach: the oss-security forward came three days after the announcement.
• Distributions: Debian lists bookworm vulnerable and unstable unfixed on 25 October.

Open questions

• Whether and when Debian, Ubuntu, Fedora and EPEL will ship fixed packages. We checked only Debian.
• How many deployments actually load the magick, wasm or tsmemcache plugins. There is no public count, and the experimental build flag keeps most stock builds clear.
• Whether vendors that build CDN or appliance products on ATS have shipped updates. We did not survey vendors and make no claim about any of them.
• Whether the downloads page date will be corrected. The date has no effect on which version to install.

What would have helped

Practices any team can use

Know what your edge proxies load. The deciding questions were "which plugins are in plugin.config" and "do we present client certificates to origins". Keep proxy configuration in version control so the answer is a grep, not a ticket to every team.

Do not build what you do not use. Experimental plugins produced three of the 15 CVEs, including the CVSS 10 critical. If one plugin forced BUILD_EXPERIMENTAL_PLUGINS on, enable only that plugin instead.

Treat optional security settings as a smell. The magick plugin had a signing key; it just did not insist on one. When a component offers optional authentication or signing, turn it on and add a config test that fails if it is off.

Scope proxy credentials. A proxy that signs object storage requests should hold read only credentials for its own bucket and prefix. That shrinks CVE-2026-111812 to reading files the proxy already serves.

Test HTTP framing at the edge. Smuggling lives between two parsers. If ATS sits behind or in front of another proxy, run desync tests against staging for each upgrade.

Read the security list, not only the release feed. The releases were announced hours before the [SECURITY] mail, as a "bugfix and security release". Route [SECURITY] subjects from announce@trafficserver.apache.org into vulnerability intake.

Rebuild fast. The upgrade is a point release; the work is finding every image that bundles the proxy. See the SBOM incident response guide and the compromised dependency playbook.

Where Safeguard fits

ATS is a C and C++ server installed from distribution packages, container images or source builds. Safeguard does not inspect live proxy traffic, read plugin.config on running hosts, detect request smuggling, or judge whether your mTLS design is sound. It would not have prevented any of these vulnerabilities and it does not replace the upgrade. Where it helps is the inventory and patching work around them:

• Finding where ATS lives. SBOM and dependency scanning covers repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image your-registry/edge-proxy:prod, safeguard scan --sbom edge-proxy.cdx.json, with JSON results under ./output). The platform shows which projects contain a given component and version. A trafficserver distribution package inside an image is the kind of component an image scan can report; an ATS built from source into a custom path may not be identified as a package at all, so check those builds by hand with traffic_server -V.
• Keeping old versions out. Policies and gates evaluated in the platform can block an image that carries an ATS version you have decided is no longer allowed.
• Doing the fix work with approval. The Safeguard CLI assistant can edit code and run commands with your approval: bumping the pinned ATS version in a Dockerfile, removing magick.so from a templated plugin.config, rebuilding the image and running proxy tests. Since CLI v11.10.0 it asks before any command that changes something. Its /permissions modes run from Ask to Strict. Autonomous remediation can open fix pull requests; it ships switched off.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. ATS is a server shipped as source tarballs and operating system packages, outside what it covers, and these issues came from the reporters the advisory credits. We make no claim that Safeguard surfaced any of them.

Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API. We could not confirm a Gold record for these CVEs while writing, so treat the ATS advisory as the source of truth.

The habit that fits an edge proxy is simple: take signed components from a source you trust, verify them, and rebuild fast when a fix lands.

Common mistakes

• Triaging by label. "Moderate" next to CVSS 10 is no reason to wait if you use origin_server_auth.
• Assuming 9.2.16 fixes all 15. It does not fix CVE-2026-111817.
• Patching hosts and forgetting images. Last month's image is still vulnerable.
• Upgrading magick users without a key. The fixed plugin will not load without one; update the URL signer first.
• Keeping unused experimental plugins installed. A .so on disk is one config line from live.
• Trusting the downloads page date for 10.2.1.
• Changing session sharing without load testing. Adding cert or none raises origin handshakes.

FAQ

Is any of this being exploited?

Not as far as public sources show. We found no report of exploitation, and none of the 15 CVEs is in the CISA KEV catalog as of version 2026.10.23. That can change; recheck KEV and the ATS lists.

What is the single most urgent item?

If plugin.config loads magick.so, that is CVE-2026-111813, unauthenticated and rated critical at CVSS 10.0 in its default configuration. Remove the line or upgrade and configure a key today. For everyone else, the request smuggling fixes are the broadest reason to upgrade, since they need no special configuration.

How do I know if the magick plugin is enabled?

Search plugin.config for magick.so. If an uncommented line exists, it is loaded. Check the plugin directory reported by traffic_layout info for magick.so to see whether it is installed at all. Stock builds do not include experimental plugins unless they were enabled at build time.

How do I disable it?

Remove or comment out its line in plugin.config, restart Traffic Server, and confirm with a test request. Optionally delete the shared object and rebuild without experimental plugins.

Why do some CVSS 10 issues say "moderate" or "important"?

Apache's label reflects impact in a default configuration. CVSS reflects the technical worst case, including non-default setups. The mTLS, SNI and AWS signing issues need specific configurations; if you have them, the CVSS score is the better guide.

Was 10.2.1 really released in August?

No. The signed 10.2.1 tag is dated 20 October 2026 at 22:34:43 UTC and the release was announced at 00:23:33 UTC on 21 October. The August date on the downloads page matches the 10.2.0 tag.

Does 9.2.16 fix all 15?

No. It fixes 14. CVE-2026-111817 has no fix in 9.2.16, and 9.2 is affected only if proxy.config.http.drop_chunked_trailers is enabled. CVE-2026-111804 does not affect 9.x at all.

I use a distribution package. What now?

Check your distribution's tracker for these CVE IDs. Debian's tracker listed bookworm's 9.2.5+ds-0+deb12u4 as vulnerable on 25 October. Until a package fix lands, apply the interim mitigations or build the upstream release.

Does Safeguard detect these vulnerabilities?

Safeguard's scanning matches components it identifies, such as a trafficserver package in a container image, against vulnerability databases. It cannot see a source built ATS that is not recorded as a package, and it does not read live proxy configuration. Verify versions with traffic_server -V regardless.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json, and runs install and tests with approval. For ATS, you would run the same loop in the repository that builds your proxy image, asking it to pin 10.2.1 or 9.2.16 and drop magick.so from the templated plugin.config. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The runner demo shows setting up the Safeguard runner on your own machine, approving it with its device code, and scanning from the terminal. Here, you would scan proxy images on an internal build host and check the JSON under ./output for any trafficserver component older than the fixed versions.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here, the folder would hold your proxy configuration, and you would approve the version bump and the plugin.config change one at a time.

Click through it at your own pace, or open it full screen.

To scan the images and repositories you build, download Safeguard and follow the CLI docs. For an earlier Traffic Server issue, see CVE-2026-33267 in Apache Traffic Server, and for the rest of the month, October 2026 security incidents and what would have helped and edge device zero-days in October 2026.

Quick check

Sources

• Apache Traffic Server security announcement: Multiple vulnerabilities fixed in 9.2.16, 10.1.5 and 10.2.1 (lists.apache.org)
• Apache Traffic Server security advisory: October 2026 CVE Release
• Apache Traffic Server announce list archive (9.2.16, 10.1.5 and 10.2.1 release mails)
• Apache Traffic Server downloads page
• GitHub: apache/trafficserver tags
• GitHub API: signed tag object for 10.2.1
• GitHub API: signed tag object for 10.2.0
• CHANGELOG-10.2.1
• CHANGELOG-10.1.5
• CHANGELOG-9.2.16
• magick plugin README (10.2.x branch)
• oss-security forward, 24 October 2026
• CVE-2026-111813
• CVE-2026-111804
• CVE-2025-31699
• CVE-2025-55702
• CVE-2026-111816
• CVE-2026-111805
• CVE-2026-111808
• CVE-2026-111814
• CVE-2026-111815
• CVE-2026-111810
• CVE-2026-111809
• CVE-2026-111811
• CVE-2026-111812
• CVE-2026-111817
• CVE-2026-112381
• ATS docs: records.yaml (server_session_sharing.match, drop_chunked_trailers)
• ATS docs 9.2.x: records.config
• ATS docs: sni.yaml (verify_client, ssl_ticket_enabled)
• ATS docs: plugins (stable and experimental)
• CISA Known Exploited Vulnerabilities catalog (JSON feed)
• Debian security tracker: trafficserver
• Debian security tracker: CVE-2026-111813

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.