Software Blog

Andrea Cosentino Apache Camel PMC Chair

Thoughts about programming, open source and more

© 2026 Andrea Cosentino

Source on GitHub

Java vulnerabilities of the week: 4 to 10 September 2026

13 min read

I keep this series going because most security news is useless to me as a developer. You get a CVE number, a CVSS score, a one line summary that says “an attacker may be able to execute arbitrary code”, and then nothing. You close the tab having learned that a thing is bad, which you already assumed, and not one word about why the thing happened or whether the same mistake is sitting in your own code.

The interesting part is always the mechanism. The exact line where a filename from the network gets joined to a path without a check. The exact handler that answers a request before it has established who is calling. Once you have seen the shape of a bug, you recognise it everywhere, and that recognition is worth far more then the score. I wrote about this at more length in the CVE stigma post back in February.

This was a heavy Apache week, and a messaging heavy one in particular. Apache Artemis shipped a batch of seven CVEs, ActiveMQ Classic shipped one, and around them sat a path traversal in Ant, a remote code execution in Impala, and a stored XSS in SkyWalking. If there is a thread running through the more interesting ones, it is trust extended too early: Ant trusts a download server to name files safely, Impala trusts an uploaded file enough to load it as a Java class, and Artemis processes protocol commands before the caller has authenticated. Not every item fits that thread, and I am not going to pretend they do, but the two I picked for the deep dives both live there.

The week in five

An honourable mention for CVE-2026-52691, a SQL injection in the Apache Griffin Hive Metastore module, disclosed 4 September 2026. It affects all versions and there is no fix, because Griffin is retired to the Apache Attic. The project’s guidance is to migrate to an alternative or restrict access to trusted users. For anyone still running it, this is a migration decision rather then a patch.

Apache Ant: the download source controls the write path

Ant has an ftp task and an scp task, both optional and both needing an extra library on the classpath (Commons Net for FTP, JSch for SCP). People reach for them in build files that pull artifacts or release bundles from a remote server. You give the task a remote pattern and a local target directory, it connects, it lists what matches, and it writes each file into the target directory.

The bug is in that last step. When the server tells Ant “here is a file, and its path is foo/bar.txt”, Ant took that path and resolved it against the local target directory to decide where to write. If the server instead returns ../../etc/something or an absolute path, the resolved destination lands outside the directory you nominated. The older code did not canonicalise the result and confirm it still sat inside the target, so the write went wherever the returned path pointed, with the file permissions of whoever launched the build.

The advisory is careful about the preconditions, and they matter. For scp, and for ftp running over FTPS, the attacker has to be the server or has to defeat the transport’s identity verification, so a correctly verified host will not feed you these paths. The softer case is a plain ftp task with no FTPS, where a machine in the middle can sit on the connection and rewrite the returned paths, because there is nothing authenticating the server at all. In a CI job that fetches from an internal FTP server over a network you do not fully control, that is not a hypothetical.

The fix in 1.10.18 adds the containment check: resolve the intended destination, confirm it is still inside the declared target directory, and refuse the write if it is not.

Why I find it interesting

This is the extraction side of the same family as Zip Slip. Zip Slip is about archive entries whose names contain ../, so unzipping them writes outside the extraction directory. This is the network download version: the entries are files a remote server offers, the names are the paths it returns, and the sink is the same unchecked “join untrusted name to trusted base directory” that has affected tar extractors, zip extractors, multipart upload handlers and now an FTP client.

The lesson I keep coming back to is that the destination of a write is data, and if any part of that data comes from the other side, it is attacker controlled until you prove otherwise. “Prove otherwise” has a precise meaning here. It is not “reject names that contain ..”, because that misses absolute paths, symlink tricks and encoding games. It is: build the full resolved path, canonicalise it, and assert that it is a descendant of the directory you meant to write into. If you are writing a Java tool that receives filenames from anywhere, from a zip, a tar, an upload, a protocol response, that containment check is the whole defence. Ant carried this bug from 1.2 to 1.10.17, which is a reminder of how long a missing check can sit in mature, heavily used code before someone points a malicious server at it.

Apache ActiveMQ Artemis: drawing the trust boundary at connection, not authentication

Artemis is the broker that grew out of HornetQ and became the next generation engine alongside the classic ActiveMQ 5.x line. It speaks several protocols, and the native one is called CORE. This week the project (now published as Apache Artemis, the same code that used to ship as Apache ActiveMQ Artemis, which is why the advisories carry both names and two version ranges) disclosed seven CVEs at once, and read together they are not seven unrelated bugs. They are one design assumption surfacing in seven places.

Look at the shape of them. CVE-2026-49363 says an unauthenticated client connecting over CORE can send a SUBSCRIBE_TOPOLOGY request before authenticating and get back the cluster’s node details. CVE-2026-49364 exposes cluster credentials to peers it has discovered, again ahead of authentication. CVE-2026-49362 lets an unauthenticated client create arbitrary durable queues over CORE, which is a write to broker state by someone who has not logged in. CVE-2026-57967 is missing authentication on CORE session reattachment. CVE-2026-67593 is a pre-authentication path in Openwire. The common phrase in almost every one is “prior to authentication” or “missing authentication”, which is CWE-306, missing authentication for a critical function, appearing across the surface.

The way I read it, the CORE handler let a connected client send commands, and the handlers for those commands assumed authentication had already happened or would be enforced elsewhere. The authentication step and the command dispatch were not strictly ordered, so a freshly connected socket could issue topology subscriptions, session reattachments and queue creations before the broker had authenticated it. The remaining two in the batch are different in kind: CVE-2026-57822 needs an authenticated client with the MANAGE permission and abuses Java deserialization of method parameters the broker never even uses, to pin a thread and cause denial of service, and CVE-2026-75880 is a message selector wildcard that also ends in denial of service. Those two are worth patching but they are not the story.

The fix is 2.57.0. One release closes all seven, which tells you they were addressed as a group, as a single reconsideration of when the broker is allowed to trust a CORE connection. The finder credited on the anchor issue is Domenico Francesco Bruscino, who works on the broker itself, so at least part of this batch came from inside the project reviewing its own protocol handling.

Why I find it interesting

A single missing authentication check is a bug. Seven of them landing together, all on the same protocol, points to something structural rather than a set of isolated slips. The trust boundary was set at “a client has connected” rather than “a client has authenticated”, and everything downstream of a connection inherited an assumption of trust that authentication had not yet established.

That is the generalisable lesson and it is not specific to brokers. Any time authentication is one step and the useful operations are other steps, the ordering between them is a security property, not an implementation detail. If a handler can run before the auth step has completed, the authentication check is not really a gate at all, whatever the design intended. The defensive posture is to make unauthenticated state its own thing that can do almost nothing, and force every meaningful command through a point where identity is already established. When you design a wire protocol, the question to keep asking is not “does this handler check permissions”, it is “can this handler even be reached before we know who is on the other end”, and this batch is a clear example of what happens when the answer is yes.

What I take away from this week

The first thread is the one I opened with, and it held up better then I expected once I had read the advisories. Ant, Impala and Artemis are three completely different pieces of software, and all three shipped a bug that comes down to trusting the other side of a boundary before that trust was established. Ant trusted a download server to return safe paths. Impala trusted a file a client uploaded enough to load it as a Java class and run it. Artemis trusted a connected socket enough to answer its commands before authentication. Different code, different decades, same shape. When you review your own systems, “what does this component trust, and has that trust been established at this point in the flow” is a question that would have caught all three.

The second thread is about where the fixes actually land, because it changes who has to do something. Most of this week is services you run, not libraries you compile against. Artemis and ActiveMQ Classic are brokers, Impala is a query engine, SkyWalking is an observability backend, and for all of them the person who has to act is whoever operates the box. There is no BOM bump in Camel or Spring Boot or Quarkus that quietly carries the fix into your application on the next dependency refresh, so if you run these brokers or clusters yourself, patching is a direct and deliberate act: Artemis to 2.57.0, ActiveMQ Classic to 5.19.11 or 6.3.2, Impala to 4.5.2, SkyWalking to the new Horizon UI. Ant is the one genuine build tool item, 1.10.18, and it reaches you the way build tools do, when you or your base image upgrade it. And Griffin reaches nobody, because it is retired and there is no release coming, so that one is a migration decision and not a patch.

The last thing worth saying is smaller. Two of these fixes were not patches at all, they were replacements: SkyWalking answered a repeat XSS by shipping a new UI project rather than patching the existing one, and Artemis closed a family of protocol bugs with a single release that redraws where authentication sits. Sometimes the honest fix for a recurring problem is to stop patching the component and rebuild the part that keeps failing. That is expensive, and its often the right call for a component that has already produced the same class of bug more than once. For the opposite case, a project investing ahead of the threat instead of reacting to it, I wrote about Camel preparing for post quantum cryptography earlier this year.

References

Read next