Apache Traffic Server: five more CVEs flip the ranking

On July 29, 2026, a batch of vulnerabilities in Apache Traffic Server went public. The fixes shipped the day before, on July 28, as 9.2.15 and 10.1.4. Among the disclosed issues, three carry a perfect 10.0 under CVSS 3.1.

Those same three, scored under the newer CVSS 4.0, come out at 7.7 / 7.0 / 7.8. That is a gap of more than three points — and both sets of numbers were assigned by Apache itself, as the CNA for these records. Read one column and the risk looks apocalyptic; read the other and it looks routine. Here is where that gap comes from, and where the version numbers will trip you up.

[Update, July 29, 2026] Five more from the same batch, and the ranking flipped

After this piece went out, five more entries from the same 38-CVE batch landed in NVD: CVE-2026-58155, CVE-2026-58154, CVE-2026-58153, CVE-2026-58151, and CVE-2026-65324. The fixes are the same 9.2.15 and 10.1.4. And one thing belongs at the top of this update: measured with CVSS 4.0, two of those five outrank the three we picked as the most severe.

The numbers say it plainly. CVE-2026-58155 and CVE-2026-58154 both score 9.2 under CVSS 4.0, which sits in 4.0's Critical band. The three we built the piece around score a perfect 10.0 under 3.1 but land at 7.8 for CVE-2026-58150, 7.7 for CVE-2026-33267, and 7.0 for CVE-2026-57834 under 4.0 — all of them High, none of them Critical. Rank all eleven by 4.0 and the only two in the Critical band are the two that showed up afterwards.

The six covered here were selected on one criterion: highest CVSS 3.1 first. By that criterion CVE-2026-58155 at 9.3 and CVE-2026-58154 at 8.9 both fell outside the cut. This article argued that ranking by a number reshuffles depending on which number you pick — and the demonstration came back at the article's own selection within hours of publication. A shortlist sorted by a single score collapses when you change the ruler. The flip runs the other way too: CVE-2026-58153 scores 8.3 under 3.1 and drops to 6.3 under 4.0.

All eleven, ranked by both rulers

Here are the original six plus the five added above, sorted by CVSS 3.1 descending, with the movement in the 4.0 ranking on the right. Ties share the higher rank.

Not one of the eleven holds its position. The largest move is CVE-2026-58154 from 6th to 1st, followed by CVE-2026-58151 from 9th to 3rd; in the other direction, CVE-2026-58153 falls from 7th to 11th. The three that scored a perfect 10.0 under 3.1 land at 5th, 6th, and 7th under 4.0.

The vectors explain the movement. CVE-2026-58155 carries AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N — note AT:N, meaning no attack requirements at all, the exact opposite of the AT:P on CVE-2026-57834 discussed further down. On top of that, integrity impact is High both on Traffic Server itself (VI:H) and on what sits behind it (SI:H). CVE-2026-58154 carries AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: memory corruption, so confidentiality, integrity, and availability of the vulnerable system are all High. Its 3.1 score stopped at 8.9 because of AC:H — and 4.0 moved that complexity into the separate AT field instead of letting it drag the base score down.

The two availability-only issues, CVE-2026-58151 and CVE-2026-65324, rise under 4.0 for the flip side of the same reason. In 3.1, A:H on its own caps out at 7.5; in 4.0, VA:H on its own reaches the mid-8s. "CVSS 4.0 scores lower than 3.1" is not a rule. Defects that chain outward to a back end come down; defects that break the server itself go up. The direction depends on the kind of flaw.

Whether HTTP/2 is enabled changes what hits you

Three of the five added entries — CVE-2026-58153, CVE-2026-58151, and CVE-2026-65324 — live in the HTTP/2 code path, with CVE-2026-65324 covering HTTP/3 as well. The other two, CVE-2026-58155 and CVE-2026-58154, are header-handling defects that apply on HTTP/1.1 and HTTP/2 alike. Counting the original six as well, four of the eleven involve HTTP/2.

Whether your instance accepts HTTP/2 is decided by the proto setting on proxy.config.http.server_ports in records.config. It is a per-port setting, and the default for TLS ports is every available protocol — so if you terminate HTTPS and have not narrowed the list explicitly, HTTP/2 is on. HTTP/3 applies only where a separate QUIC port is configured. That setting is where to start the check.

One caveat, so the table is not misread. Apache does not offer disabling HTTP/2 as a workaround for any of these five. Every entry in the announcement lists exactly one mitigation: upgrade to 9.2.15 or 10.1.4. The table above is a map for deciding what to watch while the upgrade is scheduled, not a suggestion to turn a protocol off — and turning it off carries its own performance cost.

CVE-2026-58155: over-long header names get truncated into something else

When an HTTP header name ran longer than expected, Traffic Server did not reject the request — it truncated the name. Truncate two distinct headers far enough and they collapse into the same name. That is header aliasing, and it is the foundation for a front end and a back end disagreeing about which value counts. Apache's wording is that it allows header aliasing, request smuggling, and policy bypass; the classification is CWE-444. CVSS 3.1 is 9.3 and 4.0 is 9.2, with Apache's label at important. NVD lists the affected ranges as 8.0.0–8.1.9, 9.0.0–9.2.14, and 10.0.0–10.1.3, fixed in 9.2.15 and 10.1.4. This is the highest 4.0 score of the eleven, reported by Omkhar Arasaratnam.

CVE-2026-58154: out-of-bounds writes and integer overflow in header parsing

Parsing MIME and HTTP headers, Traffic Server can write past the end of an allocation or overflow an integer. The classification is CWE-787, out-of-bounds write. Where the other ten are protocol-interpretation gaps or policy bypasses, this one is memory corruption — a successful attempt crashes the process, and depending on conditions goes further. CVSS 3.1 is 8.9 and 4.0 is 9.2, label important. Affected ranges are 8.0.0–8.1.9, 9.0.0–9.2.14, and 10.0.0–10.1.3; fixed in 9.2.15 and 10.1.4. Reported by Michael Bommarito, Omkhar Arasaratnam, and others.

CVE-2026-58153: HTTP/2 trailers forwarded without chunked framing

Trailers are headers that arrive after the body. Sending them over HTTP/1 requires the chunked transfer framing, and Traffic Server passed origin trailers received over HTTP/2 to HTTP/1 clients without putting them in that frame. The client reads them as more body, so the boundary of the response is misjudged. Classified as CWE-444, label moderate. CVSS 3.1 is 8.3 and 4.0 is 6.3 — the biggest drop of the eleven. The affected range is 10.0.0 through 10.1.3 only; 9.x and 8.x are not listed, and the fix is 10.1.4. The CVE record carries the same boilerplate recommendation as the other 37 ("upgrade to version 9.2.15 or 10.1.4"), but this entry in the official announcement lists only one line: "10.x users should upgrade to 10.1.4 or later versions." Read that as 9.x not carrying this defect.

CVE-2026-58151: abusive HTTP/2 framing and flow control

HTTP/2 multiplexes many exchanges onto one connection, managing the shares through frame splitting and flow control. Feed it hostile combinations and Traffic Server either crashes or consumes resources until it stops answering. The classification is CWE-400, uncontrolled resource consumption. CVSS 3.1 is 7.5 and 4.0 is 8.7, making it 9th of eleven by 3.1 and 3rd by 4.0 — the cleanest example of the reshuffle. Label important; affected ranges 8.0.0–8.1.9, 9.0.0–9.2.14, and 10.0.0–10.1.3; fixed in 9.2.15 and 10.1.4. Given that everything behind this machine goes down when the machine does, the 4.0 reading is arguably closer to how it feels in operation.

CVE-2026-65324: dechunking drops the per-stream buffer cap

While dechunking HTTP/2 or HTTP/3 responses, the cap on how much a single stream may buffer stops applying. With no cap, data piles up on the server for every slow reader hanging off a stream. The attacker needs no bandwidth and no privileges — reading slowly is enough to exhaust memory. Classified as CWE-400, with CVSS 3.1 of 7.5 and 4.0 of 8.2, label important. Affected ranges are 8.0.0–8.1.9, 9.0.0–9.2.14, and 10.0.0–10.1.3; fixed in 9.2.15 and 10.1.4.

How to set your own priorities

Sorting by score gives a different answer depending on the ruler. Applying your own configuration as the ruler first gives an answer that stays put. Work down this list.

• ▸Still on 8.x and there is no prioritization problem to solve. Four of the added entries (58155, 58154, 58151, 65324) list 8.0.0–8.1.9 in their CVE records, and no 8.x fix exists. Either ruler produces the same answer: migrate.
• ▸Terminating HTTPS, which means HTTP/2 is on by default, adds 58151 and 65324. Both are availability issues that look unremarkable at 7.5 under 3.1 and read 8.7 and 8.2 under 4.0 — exactly the rows a scanner sorted by 3.1 pushes to the bottom.
• ▸Running 10.x adds 58153 on top, an entry 9.x does not carry. On 9.x, the added set is four rather than five.
• ▸Regardless of protocol configuration, 58155 and 58154 hit everyone — and those are the two that reach Critical under 4.0. Header handling is a path every request takes, on HTTP/1.1 and HTTP/2 alike.
• ▸With another server behind you, the smuggling family (57834, 58150, 24033, 58155, 58153) succeeds or fails based on the pairing with that back end. The front half alone does not settle it.

Every route ends at the same place: upgrade to 9.2.15 or 10.1.4. Priorities only matter for deciding what to watch in the window before that upgrade lands. And for the record, this article covers 11 of the 38 entries; the remaining 27 are not covered here. The official announcement lists all 38 with their affected ranges.

Where Apache Traffic Server actually runs

Apache Traffic Server sits in front of websites, relays traffic, and keeps copies of frequently requested data close at hand. It is a reverse proxy and caching server: it stands between the visitor's browser and the origin site, and when the same image or page is requested again, it answers from its own copy instead of asking the origin. Deploy those boxes around the world and you have a CDN — and Traffic Server is one of the building blocks such networks are made of.

Its origin is well documented. The code began as a commercial Inktomi product; Yahoo! acquired Inktomi in 2003, ran the software internally for years, and donated the source to the Apache Software Foundation in August 2009. It became an Apache top-level project in 2010 (Wikipedia carries a summary of the timeline).

As for who runs it, the project publishes an official users list. Named there are Comcast, Yahoo!, LinkedIn, Go Daddy, Akamai, and Yahoo! Japan. The project's own site describes it as powering major CDNs and content providers worldwide. So the place these flaws land is not an individual website but the road in front of it — and it is routine for hundreds or thousands of sites to sit behind a single instance.

There is a Japanese thread running through the advisory as well. Among the credited reporters are Katsutoshi Ikenoya, Haruki Oyama, and Rajat Raghav of LY Corporation (the LINE/Yahoo Japan group). Engineers at a Japanese operator found the defects, and the fixes landed in delivery infrastructure worldwide.

The advisory covers 38 CVEs, not six

Get the scale right first. The official announcement posted by Masakazu Kitajo of the Apache Traffic Server PMC opens by stating that 38 vulnerabilities have been fixed in 9.2.15 and 10.1.4, then enumerates 38 CVE IDs. HTTP/2 resource exhaustion, integer handling in HPACK decoding, SSRF in the ESI plugin, path traversal in the Cripts framework — the sweep runs from the core all the way through the plugin set.

Six of them, including the three that hit 10.0 under CVSS 3.1, are the ones scanner alerts and news headlines will surface first. Those are the six below.

Read the right-hand columns together and the ranking flips. CVE-2026-57834 scores a perfect 10.0 under CVSS 3.1, yet Apache labels it moderate. CVE-2026-22068 only reaches 8.2, yet Apache labels it important. The numbers and the label are measuring different things in the first place.

CVE-2026-33267: hop-by-hop headers pass straight through

HTTP defines headers that are valid only for a single hop and must never be handed to the next relay. A proxy's basic duty is to strip those at the boundary. The advisory wording is that hop-by-hop and internal headers arriving from untrusted peers are not stripped; the classification is CWE-20, improper input validation. If an outsider can inject headers meant for internal use only, a backend can misread them as markers that Traffic Server itself attached. NVD records CVSS 3.1 of 10.0 and CVSS 4.0 of 7.7; Apache's label is important.

CVE-2026-58150: HTTP/2 requests with Transfer-Encoding are not rejected

HTTP/2 does not use the Transfer-Encoding header to convey body length. Traffic Server accepted it anyway and carried it along when downgrading the request to HTTP/1.1 for the backend, which opens the door to downgrade request smuggling. The classification is CWE-444, inconsistent interpretation of HTTP requests. CVSS 3.1 is 10.0 and 4.0 is 7.8 — the highest 4.0 score of the six.

CVE-2026-57834: a malformed chunked body enables smuggling

When the length of an HTTP body is not known up front, the data is sent in pieces with each piece announcing "the next chunk is N bytes." That is chunked transfer. Traffic Server handled malformed announcements loosely enough that an attacker can distort where one request is judged to end. It carries a perfect 10.0 under CVSS 3.1 while Apache's own label reads moderate. Reported by Haruki Oyama and Katsutoshi Ikenoya (LY Corporation), among others.

CVE-2026-41920: SNI and Host compared using only one side's length

SNI announces the intended domain when a TLS connection opens; the Host header states it again inside the HTTP request. The check that these two agree measured against only one of the two lengths, so a prefix match was enough to pass. Apache describes the result as a host-SNI policy bypass. The classification is CWE-284, improper access control; CVSS 3.1 is 9.3, 4.0 is 7.0, label moderate. This one entry carries contradictory version information in the public record, covered in detail below.

CVE-2026-22068: an unanchored regex lets requests slip past ACLs

Regular expressions used to match access control lists and routing rules were missing anchors — the markers that pin a pattern to the start and end of the string. The classification is CWE-777, regular expression without anchors. CVSS 3.1 is 8.2 and 4.0 is 6.9, modest by the standards of this batch, yet Apache labels it important. When a boundary you believe you configured can be walked around, the operational bite exceeds the score. More on this defect further down.

CVE-2026-24033: chunk extension quoted-string parsing

Chunked transfer allows each chunk to carry extra metadata as a "chunk extension," and those values may be wrapped in quotes. The parsing of those quoted strings was loose enough that, here too, request boundaries can be made to disagree. Classified as CWE-444, with CVSS 3.1 of 7.2 and 4.0 of 6.9, label moderate. Reported by Rajat Raghav and Katsutoshi Ikenoya (LY Corporation).

What request smuggling actually is

Three of the six (57834, 58150, 24033) are the same family. The mechanism reads like this. Web traffic travels through a relay of at least two machines: a front proxy and a back-end origin. Each request declares where it starts and stops using headers, and the front and the back can disagree about where that boundary falls. If the front counts one request where the back counts two, the leftover fragment does not vanish — it sits at the head of the back end's inbox. When the next request arrives from a completely different user, the two fuse into one, and the attacker's fragment rides in glued to the front of a stranger's request. That is why it is called smuggling; PortSwigger's write-up walks through it with diagrams.

The damage is taken seriously because the path branches three ways from there. First, cache poisoning: Traffic Server exists to store responses and hand them to other users, so if a doctored response gets stored as the copy for a legitimate URL, everyone who visits afterwards receives the attacker's content. Second, access control bypass: a request for an admin path that the front proxy is supposed to block can be tucked behind a permitted request and delivered to the back end anyway. Third, hijacking someone else's session: because the fragment fuses with a genuine user's request, the attacker's instruction can execute carrying that user's cookies and credentials, or that user's response can be routed back to the attacker.

No password needs to be broken. What breaks is the shared agreement about where a request ends. That is why this class of defect is weighted heavily in products like CDNs and reverse proxies, which by design funnel many users' traffic through a single machine.

Why two numbers from the same vendor differ by three points

Here is the heart of it. CVE-2026-57834 carries two official scores side by side: 10.0 under CVSS 3.1 and 7.0 under CVSS 4.0. Apache registered both as the assigning CNA. Neither is a mistake. They are outputs of two different formulas defined by FIRST, the body that maintains CVSS.

Lay the vectors side by side and the source of the gap shows. The 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L. Network reachable, low complexity, no privileges, no user interaction — and then S:C, scope changed, meaning the impact crosses out of the vulnerable component. With confidentiality and integrity both High on top of that, the formula pins at 10.0. In 3.1, scope change carries enough weight to push a score to the ceiling the moment it applies.

The 4.0 vector is AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L. Two things stand out. One is that impact is now recorded twice over: VC/VI/VA (impact on the vulnerable system itself) are all None, while SC/SI/SA (impact on subsequent systems) are High, High, Low. Smuggling does not break Traffic Server; it reaches past it and hits other people, so that is where the values land. Version 3.1 mixed both into one bucket and expressed the difference with a single scope flag. The other is AT:P, attack requirements present — 4.0 added a separate dimension for preconditions that must hold for the attack to work, independent of attacker effort.

The pattern that emerges is that CVSS 4.0 is built to describe more precisely how far a vulnerability reaches on its own. Issues that only succeed once a back end is configured a certain way, or once another condition lines up — the ones that need a chain — tend to land lower than in 3.1, because those preconditions now get their own field. That said, the direction and size of the gap will not be identical for every case. CVSS 4.0 also assumes threat and environmental values get layered on top of the base score, so reading a lower 4.0 as "safe" is a mistake: 7.0 and 7.8 both fall in 4.0's High band.

The practical consequence is plain. A scanner or news item that grabs only the 3.1 value of 10.0 makes this look like a fire drill; one that grabs only the 4.0 value makes it look ordinary. Both are cross-sections of the same defect. Anyone using these as decision input needs the two scores plus Apache's important/moderate label plus the exploitation status, side by side.

We covered the mirror image of this situation earlier in July, in another Apache product. With the two Tomcat issues (CVE-2026-59083 and CVE-2026-59084), scanners displayed 9.1 Critical while Apache itself rated them Low. That was a gap between an outside database's mechanically filled-in number and the vendor's own lower assessment. This time the same vendor publishes two numbers under two schemes — an internal disagreement, not an external one. The Tomcat case was solved by going to the CNA's assessment; this one is not, because both numbers are correct, both are official, and the thing worth reading is the vector behind them. Across Apache projects the real urgency varies case by case, as with the AI-discovered HTTP/2 shutdown attack and the Apache MINA flaw exploitable without any login.

An unanchored regex showed up twice on the same day

Back to what CVE-2026-22068 really is. A regular expression describes the shape of a string, and such patterns are routinely used to evaluate access control rules. What was missing were anchors — the markers that pin the pattern to the start (^) and end ($) of the string. Drop them and the test silently changes from "does this match" to "does this appear anywhere inside." A rule meant to block admin also fires on not-admin-page; used for allow decisions, it waves through any path that hides the permitted string somewhere in the middle. To the person who wrote the rule, it looks like it is working.

That defect lines up exactly with a piece we published earlier the same morning. Tegalog, a posting tool used widely across Japanese personal and fan sites, has CVE-2026-64940, which lets someone into the admin screen without logging in. Its classification differs — CWE-625, permissive regular expression — but the cause is identical: the start and end of the string were never pinned down, so input that should have been rejected got through.

Put them next to each other. One is a Perl CGI script an individual drops onto their own hosting. The other is a C++ proxy running inside Comcast's and Akamai's delivery infrastructure, moving terabits per second. Development scale, user counts, review process — nothing about them matches. And yet on July 29, 2026, both disclosed the same kind of omission. Forgetting to anchor a regex is not a defect that organizational size or code quality automatically prevents. The syntax is valid, the tests pass, and the behavior is correct for every input the author imagined. It only surfaces when somebody brings an input the author did not.

Who goes after this, and what they want

Given where this software sits, the cast of interested parties narrows on its own. Standing on that particular stretch of road are well-funded, patient attack groups that continuously map the delivery infrastructure of large CDNs, ISPs, and major media properties. Their behavior differs from the automated sweeps that harvest personal sites: they pick a target, study its configuration, and test how each front-end/back-end pairing behaves. Request smuggling depends on a disagreement between two specific implementations, so without knowing the target's stack, nothing happens — which flips the advantage toward whoever can afford the reconnaissance.

Once a target is picked, the first moves are writing into the cache, and reaching paths that were supposed to stop at the authentication boundary. The first plants a doctored response as the stored copy for a legitimate URL; replace the copy of a homepage or a shared JavaScript file and everyone arriving afterwards is served the attacker's content. The second slips a request for an administrative path — one the front proxy would refuse outright — inside a request that is permitted through. The ACL bypass in CVE-2026-22068 and the host-SNI bypass in CVE-2026-41920 widen that second doorway directly.

How this lands on the operations side rarely matches expectations. Because what was altered is a copy held mid-delivery, the origin site's files show no trace at all. An administrator can audit their own server repeatedly, find nothing wrong, and still have visitors seeing a forged page. At the same time, since the payload fuses with someone else's request, the source address in the logs belongs not to the attacker but to the legitimate user who got caught in it. With many sites sharing one proxy, the blast radius covers all of them. Time-to-detection stretches out — and that, more than any score, is why operators dislike this class of bug.

The version trap: there is no 9.1.15

This is the part most likely to cost someone real time. CVE-2026-41920 alone has conflicting affected ranges and fixed versions across the public sources. Here is the comparison.

Apache's own announcement gives, for every entry including CVE-2026-41920, an affected range of "ATS 9.0.0 to 9.2.14" and "ATS 10.0.0 to 10.1.3," with mitigation "9.x users should upgrade to 9.2.15 or later" and "10.x users should upgrade to 10.1.4 or later." The string "9.1.15" never appears in that message. The CVE record — assigned by Apache itself — says "from 9.0.0 through 9.1.14" and "upgrade to version 9.1.15 or 10.1.4," and NVD copies that text.

The artifacts settle it. On Apache's official distribution server, trafficserver-9.2.15.tar.bz2 and trafficserver-10.1.4.tar.bz2 are both dated July 28, 2026 — and there is no 9.1.15 tarball anywhere. The 9.1 line stopped at 9.1.4 on that server; 9.x LTS moved to the 9.2 line long ago. The official downloads page likewise lists exactly two current builds: 10.1.4 (Current v10.x Release) and 9.2.15 (Long Term Support v9.x Release).

On that evidence, the "9.1.14 / 9.1.15" wording in the CVE record is most likely a typo for 9.2.14 / 9.2.15. Apache has not published a correction, so this is an inference from the announcement plus the released artifacts — but the operational answer is unambiguous: if you run 9.x, the only upgrade target is 9.2.15. Do not spend time hunting for 9.1.15. The 9.2.15 build contains the fixes for all 38 CVEs in the announcement, 41920 included.

If you run 8.x, there is no patch

CVE-2026-57834 and CVE-2026-58150 both list "8.0.0 through 8.1.9" among their affected ranges in the CVE records. Four of the entries added above (CVE-2026-58155, CVE-2026-58154, CVE-2026-58151, CVE-2026-65324) list the same range, bringing the count of entries that name 8.x to six. The only fixed versions offered are still 9.2.15 and 10.1.4. So what happens to 8.x? Here is what the sources show.

• ▸Apache's announcement never mentions the 8.x branch. The only ranges listed are 9.0.0–9.2.14 and 10.0.0–10.1.3.
• ▸The last 8.x release on the distribution server is 8.1.11, dated July 25, 2024. No 8.x build accompanied this disclosure.
• ▸The project's official roadmap records 8.x as supported until March 2023, alongside a policy of keeping two major versions supported at any time. Those two are currently 9.2 and 10.1.
• ▸Why the CVE range stops at 8.1.9 — whether 8.1.10 and 8.1.11 are genuinely unaffected, or the record simply reflects the last version anyone tested — could not be determined from Apache's public information.

The answer for 8.x operators is therefore: no fix will ship for 8.x, and migrating to 9.2.15 or 10.1.4 is the only route. The branch has had no release in two years and is past its support window. Even if 8.1.11 happens to sit outside the ranges of those six, there is no way to check the status of the other 32 entries against it. Running 8.x in production is a larger exposure than any single CVE in this batch.

Exploitation status and coverage in Japan

The exploitation check first. For all six, no reports of real-world attacks and no published proof-of-concept code could be found in public sources. None of the six appear in CISA's Known Exploited Vulnerabilities catalog either. How to read that catalog is covered in our guide to the list of vulnerabilities under active attack.

Discount that finding for how fresh this is. The CVE records went public on July 29, 2026, and the fixed builds landed the day before. Reverse-engineering an exploit from the patch diff typically starts within hours of disclosure. "No exploitation observed" is not "will stay safe."

On Japanese-language coverage: as of writing, no entry for this advisory could be found at JVN or JPCERT/CC, and no domestic technical press coverage either. Tomcat and HTTP Server issues routinely get JVN entries; Traffic Server has a lower profile in Japan, so Japanese-language information tends to lag. As noted above, several of the credited reporters work at LY Corporation, which makes this anything but remote for large Japanese operators.

What to do

Three things to check around the upgrade. First, whether your Traffic Server faces the internet directly. Even behind a CDN or load balancer, smuggling exploits a disagreement between a front and a back — having another proxy in front is not in itself protection. Second, whether your remap rules or ACLs use regular expressions. That is the surface CVE-2026-22068 touches, and it is worth auditing the anchors while you are already in there. Third, a plugin inventory. A sizeable share of the 38 entries live in plugins such as ESI, header_rewrite, regex_remap, ts_lua, and url_sig; if you are loading plugins you do not use, removing them shrinks the attack surface by itself.

On detection, smuggled traffic is hard to distinguish from legitimate traffic in access logs. Even so, unusually high request counts on a single connection, requests carrying both Content-Length and Transfer-Encoding, and HTTP/2 requests containing Transfer-Encoding are searchable signals after the fact. Checking whether any of those appear in the logs from before the upgrade gives you something to reason from later.

Frequently asked questions

Q. Our scanner reports CVSS 10.0. Should we take the service down?

A. That is not what the evidence calls for. Apache assigned the same issue a CVSS 4.0 value of 7.0 and a severity label of moderate. Meanwhile the fix already exists and exploitability depends on your stack. Plan the upgrade to 9.2.15 or 10.1.4, but do not postpone it — that is the proportionate response.

Q. We cannot find 9.1.15. Where is it?

A. It does not exist. The CVE record for CVE-2026-41920 names 9.1.15, but neither Apache's announcement nor the distribution server has such a build, and it appears to be a typo for 9.2.15. The 9.x upgrade target is 9.2.15.

Q. We run 8.1.11. Are we outside the affected range?

A. The CVE records stop at 8.1.9, but no fix ships for 8.x and the branch has had no release since 8.1.11 in July 2024. Six entries now name 8.x once the added five are counted, and with no way to check the remaining 32 against it, there is no basis for declaring yourself unaffected. Plan a migration to 9.2.15 or 10.1.4.

Q. Should internal reporting use CVSS 3.1 or 4.0?

A. Either one alone will mislead. Report both, and attach Apache's severity label and the KEV status. If your process forces a single number, this batch is a good occasion to confirm that the process breaks on cases like it.

Summary

Apache Traffic Server vulnerabilities were disclosed as a batch on July 29, 2026, with 9.2.15 and 10.1.4 shipping as the fixes. The official announcement enumerates 38 CVEs, three of which reach 10.0 under CVSS 3.1 — and those same three score 7.7 / 7.0 / 7.8 under CVSS 4.0, with both figures assigned by Apache. The gap comes from 4.0 separating impact on the product itself from impact on what lies beyond it, and giving preconditions their own field. Judging from one column alone goes wrong in either direction.

Three operational takeaways. The 9.x upgrade target is 9.2.15; the 9.1.15 named in the CVE record does not exist. No fix exists for 8.x, so migration is the only option. And no exploitation or PoC could be found in public sources, with nothing listed in KEV — though the disclosure is only hours old, which is a different thing from being safe. Between the Tomcat case where outside scores clashed with the vendor's own rating and this one where the vendor publishes two ratings itself, both show the same limit: managing vulnerabilities by a single score does not hold.

That limit came back at this article within hours of publication. Five more entries from the same batch arrived, and the two that top the list under CVSS 4.0 — CVE-2026-58155 and CVE-2026-58154 — were the ones a shortlist sorted by CVSS 3.1 left out. The details are in the update block near the top. Pin the ranking to one number and this is what happens, on the writing side as much as the operations side.

References

• ▸Apache official announcement - Multiple vulnerabilities fixed in Apache Traffic Server 9.2.15 and 10.1.4
• ▸Apache distribution server - Traffic Server release listing
• ▸Apache Traffic Server - Downloads (current releases)
• ▸Apache Traffic Server - Users (official adopter list)
• ▸Apache Traffic Server - ATS Release Roadmap (support windows)
• ▸CVE.org - CVE record for CVE-2026-41920
• ▸NVD - CVE-2026-33267
• ▸NVD - CVE-2026-57834
• ▸NVD - CVE-2026-58150
• ▸NVD - CVE-2026-22068
• ▸NVD - CVE-2026-24033
• ▸NVD - CVE-2026-58155 (added)
• ▸NVD - CVE-2026-58154 (added)
• ▸NVD - CVE-2026-58153 (added)
• ▸NVD - CVE-2026-58151 (added)
• ▸NVD - CVE-2026-65324 (added)
• ▸CVE.org - CVE record for CVE-2026-58153 (10.x only)
• ▸Apache Traffic Server - records.config (proto on server_ports)
• ▸FIRST - CVSS v4.0 specification
• ▸FIRST - CVSS v3.1 specification document
• ▸MITRE - CWE-444: Inconsistent Interpretation of HTTP Requests
• ▸MITRE - CWE-777: Regular Expression without Anchors
• ▸MITRE - CWE-787: Out-of-bounds Write
• ▸MITRE - CWE-400: Uncontrolled Resource Consumption
• ▸PortSwigger - HTTP request smuggling
• ▸CISA - Known Exploited Vulnerabilities Catalog
• ▸Computerworld - Yahoo donates Traffic Server to Apache (2009)