Bonus, the man in the middle can see what packages you’re downloading since you’re not using HTTPS, so they know if you’re vulnerable during an update.
I never understood the insistence on using HTTP as a default for apt. Once HTTPS transport was available and tested (which took forever btw) then it should have become the default. Maybe this will spur some changes.
If your scale actually makes caching worth it you can run a local HTTPS mirror. If you don't control the endpoints to do that, you don't get to MiTM anything.
No word as of yet if Ubuntu's apt is also impacted.
Sounds like the vulnerability is in the HTTP handling code, and because apt downloads packages over plain HTTP a man-in-the-middle position would be enough to exploit it.
It almost seems like a repeat of two previous apt vulnerabilities:
Despite with the 'no need for TLS, apt packages are signed' clowns would have you believe, you can usually point to a package mirror with https. This has the added advantage of preventing a mitm from knowing what packages you install or blocking selected packages.
> Updates for the affected Debian, Debian LTS, Debian eLTS, Ubuntu, and Ubuntu Pro channels are being released.
>
> An update for apt 1.0.1ubuntu2.24 has been made available to Ubuntu Pro customers running Ubuntu "trusty" through the Ubuntu Pro subscription service, and a 3.3.3ubuntu0.1 for stonking.
An attacker might replace a package with a previous one which has a vulnerability. Downgrade attack. Unclear if the apt client will check if version is the expected one after requesting a package.
Of course not, Debian is one of the most robust pieces of software around. They wouldn't do something idiotic like relying on the hash being sent with the payload through the same channel.
I think the idea is that debian distributes the hash themselves through their domain, and mirrors offer the downloads either through http or https. So that you don't need to trust the mirror, you just verify the debian given hash. Only weakness would be a hash collision or a cve like this.
AFAIK this isn't actually true for any distribution. This would break selfhosted mirrors and their clients hosted on airgapped networks, and create a single point of failure for users.
The way packages are validated actually is through the same channel as you download the packages themselves from (IE your mirror), they just are signed with the Debian package signing key(ring), of which only a select few maintainers have authorized private keys for.
This does mean an adversary (whether a MITM if you're using HTTP or malicious operator on the mirror server itself) can technically serve you old versions of an (officially signed) package indefinitely and your package manager would be none the wiser, but otherwise this approach actually works quite well.
Well, of course there is "Selbstreparaturparadoxon", but nobody uses that. This is more like a Münchhausen-Problem, where Baron Münchhausen pulls himself out of the swamp by his own hair.
Not surprised at all. I remember all of the heated discussions (even here on HN) around there being absolutely no need for HTTPS because "everything is signed with PGP".
Exposing all of the internals of something to any and all MITM keeps on demonstrating how it's a dangerous idea.
Hopefully this example settles at least some of this pointless discussion.
Since this is the second time the redirect feature was broken in a serious way and there is still no obvious need for it.. time to make it opt-in instead of opt-out?
There have already been quite a few vulnerabilities in the implementation that would have been avoided if the transport itself was simply protected in line with the industry standard practice of using TLS by default.
The ones I looked at could be summed up to "well the redirects are misbehaving again"
Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.
The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.
There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.
Still places trust in the download servers, which makes them a juicy target
But yes, they could have mentioned HTTPS to make the announcement at least half-assed. Even just saying "good luck not getting exploited" would be an improvement over literally nothing
A compromised mirror cannot serve packages that aren't properly signed.
This attack used an HTTP redirect to serve a backdoored package after the signature has been verified. I'm not sure that HTTP redirect attack would work with an HTTPS repository!?
Yikes, that vuln in apt is pretty bad! I think a lot of the newer wave of vulnerabilities being found generally seem to have a low likelihood of being reached, but this seems somewhat plausible? I'm assuming this would be done by compromising a mirror, in order to do the redirect?
More likely just a man in the middle attack. Apt typically uses HTTP (no TLS) as the signatures give the security. But in this case it sounds like the vulnerability is that after a successful signature check the legit file can be overridden by the attacker through some HTTP shenanigans.
It's not 'Attack Vector: Network' in cvss, so it's probably scoring lower than a 7.
EDIT: With 'AV:Adjacent Network' and A 'User Interaction: Required' and max impact (High on Confidentiality, Integrity and Availability, assuming worst case), then it gets a score of 8.
The subjectives lower the severity to my eyes as well, including the use of HTTP mirrors (which is the default notwithstanding), and the attacker needing to be an existing mirror at the time of the announcement, which is already a vetted group (or be in the path between the user and the mirrors, umm that is quite possible though, but quite hard to target). And finally the window for the disclosure and attacks is almost null, someone needs to use apt to be vulnerable, but if they use apt, they are probably autoupdating apt itself, I wonder if a simple 'apt install thing' will trigger an apt upgrade, in order to patch those that are not running autoupgrades.
I always strongly argue against framing MITM scenarios as AV:Adjacent as MITM attacks can be performed at any point of the transmission path. If someone MITMs the package mirror the attacker is certainly not adjacent to the vulnerable component. I argue in favor of using Attack Complexity: High instead, as you do need to be in a MITM position.
And while UI:Required could be argued, there are also unattended upgrades and updates are performed regularly anyway. CVSS 4 makes some progress here with UI active vs passive, but ultimately CVSS is often not helpful for capturing the unique risk of a vulnerability.
This is my best guess on what's happening based on the limited information linked.
1) Apt downloads first package (unmodified)
2) apt checks signature -> signature checked and remembered as valid
3) apt downloads second package, http redirect to the same url as package 1
4) the second package overwrite first one due to sharing URL. The temporary storage name or download cache key is derived from URL.
5) signature for package 2 fails but first one (already overwritten by bad one) is still considered good
6) Package 1 gets executed because the signature check already passed in step 2
Note sure where exactly resuming an HTTP download fits in. Maybe step 4 also requires pausing and resuming the update process. Which could involve some state serialization/deserialization vulnerable to conflicting URL confusion.
> APT can merge two different package downloads after an HTTP redirect gives
them the same URI
It sounds like the verification is ran but there is some deduplication or caching involved keyed on the destination of the url redirect, not the original source.
So could imagine a malicious server that:
Responds for a request for foo.deb with a redirect to evil.deb containing the original foo.deb. This validates properly.
Responds with a second request for bar.deb with a redirect again to evil.deb that now returns a malicious package. The downloading code thinks it has already validated evil.deb
Bonus, the man in the middle can see what packages you’re downloading since you’re not using HTTPS, so they know if you’re vulnerable during an update.
I never understood the insistence on using HTTP as a default for apt. Once HTTPS transport was available and tested (which took forever btw) then it should have become the default. Maybe this will spur some changes.
How to cache with HTTPS?
If your scale actually makes caching worth it you can run a local HTTPS mirror. If you don't control the endpoints to do that, you don't get to MiTM anything.
https://wiki.squid-cache.org/Features/SslPeekAndSplice
give the cache server a certificate?
SSL bumping
No word as of yet if Ubuntu's apt is also impacted.
Sounds like the vulnerability is in the HTTP handling code, and because apt downloads packages over plain HTTP a man-in-the-middle position would be enough to exploit it.
It almost seems like a repeat of two previous apt vulnerabilities:
In 2019: https://lists.debian.org/debian-security-announce/2019/msg00...
And in 2014: https://lists.debian.org/debian-security-announce/2014/msg00...
Despite with the 'no need for TLS, apt packages are signed' clowns would have you believe, you can usually point to a package mirror with https. This has the added advantage of preventing a mitm from knowing what packages you install or blocking selected packages.
> preventing a mitm from knowing what packages you install
Package size is unique enough that just seeing the size of the transfer will usually be enough to tell.
well when CA use 4 as key that kinda matters less
They usually don't.
Every mirror will know that because of HTTPD logs.
In fairness to GP, that wouldn't be a man in the 'middle', the mirror is the end destination for your traffic.
> Updates for the affected Debian, Debian LTS, Debian eLTS, Ubuntu, and Ubuntu Pro channels are being released. > > An update for apt 1.0.1ubuntu2.24 has been made available to Ubuntu Pro customers running Ubuntu "trusty" through the Ubuntu Pro subscription service, and a 3.3.3ubuntu0.1 for stonking.
From the original disclosure: https://lists.debian.org/deity/2026/11/msg00005.html
For context, Ubuntu trusty and apt 1.0.1 is from 2014.
I thought there might be some kind of hash or signature, but I’m assuming that can be forged along with the main payload?
From the short description in the advisory, would seem like the attacker can cause the tool to overwrite the file after signature verification.
An attacker might replace a package with a previous one which has a vulnerability. Downgrade attack. Unclear if the apt client will check if version is the expected one after requesting a package.
Of course not, Debian is one of the most robust pieces of software around. They wouldn't do something idiotic like relying on the hash being sent with the payload through the same channel.
I think the idea is that debian distributes the hash themselves through their domain, and mirrors offer the downloads either through http or https. So that you don't need to trust the mirror, you just verify the debian given hash. Only weakness would be a hash collision or a cve like this.
AFAIK this isn't actually true for any distribution. This would break selfhosted mirrors and their clients hosted on airgapped networks, and create a single point of failure for users.
The way packages are validated actually is through the same channel as you download the packages themselves from (IE your mirror), they just are signed with the Debian package signing key(ring), of which only a select few maintainers have authorized private keys for.
This does mean an adversary (whether a MITM if you're using HTTP or malicious operator on the mirror server itself) can technically serve you old versions of an (officially signed) package indefinitely and your package manager would be none the wiser, but otherwise this approach actually works quite well.
The signatures do expire (which is an annoyance when working with snapshot.debian.org).
Ubuntu is affected.
> We recommend that you upgrade your apt packages.
Is there a German word for a broken tool that can only be fixed by using the same broken tool?
Well, of course there is "Selbstreparaturparadoxon", but nobody uses that. This is more like a Münchhausen-Problem, where Baron Münchhausen pulls himself out of the swamp by his own hair.
For what it's worth there is an apt "Acquire::http::AllowRedirect" option that can be disabled.
> For what it's worth there is an apt "Acquire::http::AllowRedirect"
Odd, I am not familiar with that that German word.
Is this the right way to specify it when upgrading the vulnerable apt?
Münchhausenwerkzeug.
Not surprised at all. I remember all of the heated discussions (even here on HN) around there being absolutely no need for HTTPS because "everything is signed with PGP".
Exposing all of the internals of something to any and all MITM keeps on demonstrating how it's a dangerous idea.
Hopefully this example settles at least some of this pointless discussion.
That's exactly why layered security is a thing since ever. Weird that some argued that a singular layer is sufficient.
Since this is the second time the redirect feature was broken in a serious way and there is still no obvious need for it.. time to make it opt-in instead of opt-out?
It's always been strange to me and I've been saying forever that I don't get why package repos don't use HTTPS.
Easier to put caching proxies on the path?
Who actually does that this day and age?
Developers
I do. Helps massively when seeding virtual machines using auto-install scripts.
It's not the default, but you can install apt-transport-https and then just change the update URLs to https assuming your mirror supports that.
you can just change the urls to https, apt-transport-https isn't needed anymore, it's builtin to apt now.
I would speculate that it's inertia due to decisions made a decade or two ago, before we decided that everything should run via HTTPS.
theoretical model means that the transfer method doesn't matter.
Of course, that breaks if implementation checks the signatures in wrong moment
There have already been quite a few vulnerabilities in the implementation that would have been avoided if the transport itself was simply protected in line with the industry standard practice of using TLS by default.
The ones I looked at could be summed up to "well the redirects are misbehaving again"
Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.
The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.
There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.
I get it to a point because it can be a chicken and egg situation sometimes, but there has got to be a better way.
Would it have killed them to give even a little bit of guidance how to securely update the apt package(s)?
If necessary, with instructions for downloading and verifying it out of band
Or maybe by passing a parameter to the old apt that disables the vulnerable HTTP download resumption when downloading the new apt
Use https?
Still places trust in the download servers, which makes them a juicy target
But yes, they could have mentioned HTTPS to make the announcement at least half-assed. Even just saying "good luck not getting exploited" would be an improvement over literally nothing
And APT was the one being very reluctant about using HTTPS because "we sign out stuff so don't need encryption".
I think this demonstrates exactly why everything should be https.
HTTPS will not protect you from a bad/compromised mirror.
Wait: Debian packages are signed.
A compromised mirror cannot serve packages that aren't properly signed.
This attack used an HTTP redirect to serve a backdoored package after the signature has been verified. I'm not sure that HTTP redirect attack would work with an HTTPS repository!?
Why wouldn't it work on a compromised mirror? HTTPS servers can still do redirects.
A bad mirror is much less likely than someone MiTMing, at least for most machines.
If I understand correctly, trixie-security contains a fixed version, however, bookworm not (yet)?
Is it going to be fixed for oldstable?
https://security-tracker.debian.org/tracker/CVE-2026-109518
bookworm-security has the fix
Yikes, that vuln in apt is pretty bad! I think a lot of the newer wave of vulnerabilities being found generally seem to have a low likelihood of being reached, but this seems somewhat plausible? I'm assuming this would be done by compromising a mirror, in order to do the redirect?
More likely just a man in the middle attack. Apt typically uses HTTP (no TLS) as the signatures give the security. But in this case it sounds like the vulnerability is that after a successful signature check the legit file can be overridden by the attacker through some HTTP shenanigans.
Well, at least it's Debian, so even if they used HTTPS they'd still be vulnerable!
I didn't know that about apt, interesting choice!
It's not 'Attack Vector: Network' in cvss, so it's probably scoring lower than a 7.
EDIT: With 'AV:Adjacent Network' and A 'User Interaction: Required' and max impact (High on Confidentiality, Integrity and Availability, assuming worst case), then it gets a score of 8.
The subjectives lower the severity to my eyes as well, including the use of HTTP mirrors (which is the default notwithstanding), and the attacker needing to be an existing mirror at the time of the announcement, which is already a vetted group (or be in the path between the user and the mirrors, umm that is quite possible though, but quite hard to target). And finally the window for the disclosure and attacks is almost null, someone needs to use apt to be vulnerable, but if they use apt, they are probably autoupdating apt itself, I wonder if a simple 'apt install thing' will trigger an apt upgrade, in order to patch those that are not running autoupgrades.
Nitpick about CVSS scoring:
I always strongly argue against framing MITM scenarios as AV:Adjacent as MITM attacks can be performed at any point of the transmission path. If someone MITMs the package mirror the attacker is certainly not adjacent to the vulnerable component. I argue in favor of using Attack Complexity: High instead, as you do need to be in a MITM position.
And while UI:Required could be argued, there are also unattended upgrades and updates are performed regularly anyway. CVSS 4 makes some progress here with UI active vs passive, but ultimately CVSS is often not helpful for capturing the unique risk of a vulnerability.
interesting, why is verification not running after package is already on hard drive in full ?
This is my best guess on what's happening based on the limited information linked.
1) Apt downloads first package (unmodified)
2) apt checks signature -> signature checked and remembered as valid
3) apt downloads second package, http redirect to the same url as package 1
4) the second package overwrite first one due to sharing URL. The temporary storage name or download cache key is derived from URL.
5) signature for package 2 fails but first one (already overwritten by bad one) is still considered good
6) Package 1 gets executed because the signature check already passed in step 2
Note sure where exactly resuming an HTTP download fits in. Maybe step 4 also requires pausing and resuming the update process. Which could involve some state serialization/deserialization vulnerable to conflicting URL confusion.
based only on the wording in the notice:
> APT can merge two different package downloads after an HTTP redirect gives them the same URI
It sounds like the verification is ran but there is some deduplication or caching involved keyed on the destination of the url redirect, not the original source.
So could imagine a malicious server that:
Responds for a request for foo.deb with a redirect to evil.deb containing the original foo.deb. This validates properly.
Responds with a second request for bar.deb with a redirect again to evil.deb that now returns a malicious package. The downloading code thinks it has already validated evil.deb
[flagged]
yey, my computers and containers aren't vulnerable (^-^)
[flagged]
I’ll just note that you had to go back more than 20 years to get that short list of complaints.
>How are you going to update if apt is compromised?
Download the package with your http client of choice, install with sudo dpkg --verify -i
many mirrors are also available over https, you can just change that
Basically all of them are, many of the larger mirror servers host multiple distributions, with some defaulting to/requiring HTTPS nowadays anyway.
[flagged]
[flagged]