curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
Worth noting that people on RedHat still haven't received proper updates, only a workaround that disables two Comodo root certificates that were used to sign the emudhra certificates.
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
Commercial support in Linux seems to be loosing its advantage over Debian.
Ubuntu (including Ubuntu Pro) still doesn't have a CVE-2026-99999 patch while Debian does have it. For commercial operators a KVM guest escape vulnerability is quite important.
I honestly think you're better off with RHEL. They might have been slow to act in this situation, but do one scan on a Debian vs a RHEL system container image and I'm confident Debian's will show a lot more red than RHEL (even with the fedora)
I remember RHEL being quite slow with copyfail as well. It'd be nice to have some more comprehensive statistics though.
And I don't put a lot of faith in container scans as a metrics. (More properly, I don't have faith in most containers scanners to properly identify package versions and backports.)
This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.
Well, that is what people who have been around the block a few times have been saying about containers since just about forever. "I don't want to be an admin for my n software packages, I'll use containers!" - now you are the admin of n containers, except with worse tools than your distro and no upstream support.
And since before that, when we started turning to additional packages managers installed with package managers. Pip etc. mean that an “apt upgrade” isn’t enough, when it really “should” be (used to be) in a well managed system.
Then we layered _another_ level of package management on top with Flatpak etc.
I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.
[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]
[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]
It's funny that no one seems to even consider using the distro package manager when it's time to complain about Python package management again. The deployment environment is usually well-known thus scriptable, and developers can be expected to know how to install packages on their own distros. And, of course, if the package is deployed as part of a distro, everything is taken care of by the distro people.
Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.
Nobody seriously considers it because usually, especially in enterprise distros, the major versions are years out of date and missing many features. And many smaller packages just won't be available. Even for something as major as Django it just wasn't viable to use the OS package manager when I tried it in the Debian 8 and then 9 days.
Only one company I've worked at maintained their own distro packages for deploying services. That was 13+ years ago. Every company since then had a containerized deployment strategy, some better than others. My most recent employer went through a massive effort to implement "golden base images" and tooling to ensure when the base image is updated all the dependents are rebuilt and redeployed. Most don't do that.
I use some rules and a few generated scripts and have a LLM handle the management of the containers. Security through a ssh gateway, allows them to deploy/remove containers and then the rule is to stay at least two weeks behind on releases, unless the latest release is security related, which it figures out by reading the release notes.
I ran watchtowerr before, but I think this is a smarter way to do it.
For me, this comment actually bolsters the argument for containers imo. It's a lot easier to rebuild a system image and redeploy it out across a bunch of apps than it is to update a bunch of VMs (maybe ansible/puppet makes it moot). Idk
Python environment was so brittle, that a solution was found: pack dependencies into "envs" of various kinds. Disk space is cheap, after all (ahem). Now it's time to pay the bill for that approach...
Yeah, at some point I gave up and asked AI to do patching for me. It was a good call because it found affected certificates in places where I wouldn't look (e.g. aws-cli or Libre Office).
cool cool cool. Don't understand what you're doing, and keep not understanding what you're doing. the agents are infallible after all, and who cares about properly verifying certs anyway? that's nerd shit.
don't worry. if you're in this situation with this attitude, you're likely running out of date container base images and whatnot.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
No, it's a reference/joke to the old controversy regarding master/slave naming in computer circles. I don't know how far back that controversy goes, I probably heard about it about a decade ago.
Countless and countless, no, millions of male developers felt discriminated against whenever someone called it Man-in-the-middle. This went on unaccounted for for decades! Finally we’re being seen!
Not to mention all the women who were misogynisticly attacked by assuming women can’t be hackers.
Finally justice. It’s very important that we’re getting our priorities right when talking about security vulnerabilities!
As a sentient cephalopod who has enjoyed hacking staff computers when I slip out of my tank at the National Aquarium every night, I can only say it feels good to be seen. We're finally making progress on de-centering hominid perspectives in favor of a more diverse range of natural intelligences!
That's not the case, Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
> Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
Reminder: Neither the CVE nor the linked go alert seem to say that you have to recompile and redeploy your application with the new go version in order to take advantage of this change. Just updating the tool chain and go stdlib isn't enough, because this stuff gets baked into the resultant binary. This is unlike, say, python, Ruby, or java where updating the runtime may be sufficient, depending on your development and deployment model.
Go is not vulnerable in the same way software using webpki is, because it generally uses the system trust store. However, this change is about golang proactively blocking the certs, so that even if your OS doesn't update, it still won't trust them.
Certificate authority (eMudhra) generated eight of its intermediate signing keys so badly that anyone can recover the private keys from the public certificates. That means anyone can mint a "valid" HTTPS certificate for any site, such as your bank, GitHub, or PyPI, and impersonate it.
For desktop/most server software, they usually defer what to trust to the operating system, so if you've updated your OS' cacerts package they would likely have been revoked.
The really fun stuff are stuff like:
1. embedded and IOT stuff that doesn't ever get OS updates or even have an OS. People are using this to MITM stuff like smart TVs and household appliances and then pwn them.
2. In some cases a Linux container is run in a context where the OS is hidden from it (think serverless/container as a service type platforms). It might not have access to the OS trust store and have to fall back on the one built into the stdlib.
A lot of software is going to be forced to update or retire soon, all unpatched software should be retired off the internet immediately because AI agents are in waiting.
Great. The technology has progressed enough to kill the existing technologies. It's like the fish in a pool creating a shark that eats away all the fish while the fish proudly announce that their great creation (shark) as the frontier progress for their fish race.
Agents have dramatically increased the ability to poke at every single surface out there. I would be surprised if the researcher who found this wasn't assisted by a llm.
The researcher in question has publicly stated[0] that he wanted to try Google's paranoid_crypto tool[1], so he ran it on some roots as a quick proof-of-concept, and the first thing that happened was that it detected these intermediates. He also states he's been running a lot of certificate linters so this was just the next logical step I guess.
That was an enlightening read. I find it incredible that apparently Google themselves don't use the existing corpus of certificates as a test for paranoid_crypto.
My biggest worry now is what's going to happen with the amount of unemployed software developers seeing these vulnerabilities and not able to bring money to pay the bills.
No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why this link is on the front page as it duplicates previous posts and confuses people, I think it should be merged.
I've had since Debian 8 (2015) few helper scripts to make me remember better how to manage approved CA's. There are three of those, which have been working all Debian versions since 8 to current 13.
# cat /usr/local/sbin/ca-certificates-list-active
#!/usr/bin/env bash
#
# BFMI tool to list Debian CA certificates active - mesrik, 2015
#
CA_CONFIG=/etc/ca-certificates.conf
CA_REPO_DEBIAN=/usr/share/ca-certificates
if [ -f $CA_CONFIG ]; then
# study any ca-certificates which have been configured active
for i in $(egrep -v '^[#!]' /etc/ca-certificates.conf) ; do
cert_source=$(dirname $i)
cert_file=$(basename $i)
openssl x509 -in $CA_REPO_DEBIAN/$cert_source/$cert_file -noout -subject |\
sed 's/^subject=//'
done
else
echo "$(basename $0): Ooops, was not able to access $CA_CONFIG"
fi
# eof
#!/usr/bin/env bash
#
# BFMI tool to invalidate all CA certificates in Debian Jessie - mesrik, 2015
#
CA_CONFIG=/etc/ca-certificates.conf
prog=$(basename $0)
usage="Usage: $prog { -commit }"
if [ $# -lt 1 ]; then
echo $usage
exit 1
fi
if [ "$1" = "-commit" ]; then
if [ -f $CA_CONFIG ]; then
backup_ext=$(date -r $CA_CONFIG +".%FT%T%z")
perl -wpi$backup_ext -e 's/^([^!#].*)$/!$1/;' $CA_CONFIG
if [ $? -eq 0 ]; then
echo "$prog: backup $CA_CONFIG$backup_ext was made."
/usr/sbin/update-ca-certificates
fi
else
echo "$prog: Ooops, was not able to access $CA_CONFIG"
fi
else
echo "$prog: Need -commit to actually invalidate all CA's"
fi
# eof
ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
Gentoo Linux users are adviced to update the package "app-misc/ca-certificates" to version "20260816.3.125" or higher!:
To check via "curl": They should return: ---* GLSA 202610-01: https://security.gentoo.org/glsa/202610-01
* https://emudhra.we-have-a-problem.com/
Worth noting that people on RedHat still haven't received proper updates, only a workaround that disables two Comodo root certificates that were used to sign the emudhra certificates.
https://access.redhat.com/security/vulnerabilities/RHSB-2026... - "Ongoing"
RHEL also got the PHP patches hours after Debian.
I chose AlmaLinux last time I needed to, and it's been a great way to access the ecosystem — I heartily recommend it as a free RHEL! — but these past few days have me looking in envy at Debian. Corporate stability hasn't been what I expected.
Commercial support in Linux seems to be loosing its advantage over Debian.
Ubuntu (including Ubuntu Pro) still doesn't have a CVE-2026-99999 patch while Debian does have it. For commercial operators a KVM guest escape vulnerability is quite important.
I honestly think you're better off with RHEL. They might have been slow to act in this situation, but do one scan on a Debian vs a RHEL system container image and I'm confident Debian's will show a lot more red than RHEL (even with the fedora)
I remember RHEL being quite slow with copyfail as well. It'd be nice to have some more comprehensive statistics though.
And I don't put a lot of faith in container scans as a metrics. (More properly, I don't have faith in most containers scanners to properly identify package versions and backports.)
Python users may need to take their own separate steps, see this discussion:
https://discuss.python.org/t/information-for-python-users-re...
This is such a clusterfuck. I use so many containers in my home lab and various local installations and stuff. Honestly, I have no idea what I'm even supposed to do at this point because I'm not a full time developer.
Well, that is what people who have been around the block a few times have been saying about containers since just about forever. "I don't want to be an admin for my n software packages, I'll use containers!" - now you are the admin of n containers, except with worse tools than your distro and no upstream support.
And since before that, when we started turning to additional packages managers installed with package managers. Pip etc. mean that an “apt upgrade” isn’t enough, when it really “should” be (used to be) in a well managed system.
Then we layered _another_ level of package management on top with Flatpak etc.
I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.
[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]
[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]
It's funny that no one seems to even consider using the distro package manager when it's time to complain about Python package management again. The deployment environment is usually well-known thus scriptable, and developers can be expected to know how to install packages on their own distros. And, of course, if the package is deployed as part of a distro, everything is taken care of by the distro people.
Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.
Nobody seriously considers it because usually, especially in enterprise distros, the major versions are years out of date and missing many features. And many smaller packages just won't be available. Even for something as major as Django it just wasn't viable to use the OS package manager when I tried it in the Debian 8 and then 9 days.
Only one company I've worked at maintained their own distro packages for deploying services. That was 13+ years ago. Every company since then had a containerized deployment strategy, some better than others. My most recent employer went through a massive effort to implement "golden base images" and tooling to ensure when the base image is updated all the dependents are rebuilt and redeployed. Most don't do that.
I use some rules and a few generated scripts and have a LLM handle the management of the containers. Security through a ssh gateway, allows them to deploy/remove containers and then the rule is to stay at least two weeks behind on releases, unless the latest release is security related, which it figures out by reading the release notes.
I ran watchtowerr before, but I think this is a smarter way to do it.
One could say comeuppance is a dish best served cold. So cold people don’t even know it’s been served. All the old sys admins remember!
For me, this comment actually bolsters the argument for containers imo. It's a lot easier to rebuild a system image and redeploy it out across a bunch of apps than it is to update a bunch of VMs (maybe ansible/puppet makes it moot). Idk
Python environment was so brittle, that a solution was found: pack dependencies into "envs" of various kinds. Disk space is cheap, after all (ahem). Now it's time to pay the bill for that approach...
"Hey claude this is the cve I need you to fix [link]"
Takes about 20 seconds. Depending if you need to hit enter.
Yeah, at some point I gave up and asked AI to do patching for me. It was a good call because it found affected certificates in places where I wouldn't look (e.g. aws-cli or Libre Office).
cool cool cool. Don't understand what you're doing, and keep not understanding what you're doing. the agents are infallible after all, and who cares about properly verifying certs anyway? that's nerd shit.
don't worry. if you're in this situation with this attitude, you're likely running out of date container base images and whatnot.
i highly suggest you forget about containers, learn about systemd unit file hardening, and then you only have to play sysadmin to your base os and the binary for the program you want to run.
uv should be your friend.
uv defaults to its own trust store afaik lol
maybe they meant it "should" be your friend but actually isn't in this case :-)
Welcome to corporate
> Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .
Monster?
Gender-neutral variant of man-in-the-middle. They should have just used something less controversial like master-in-the-middle.
The women developers would like to cede this gender-neutral replacement back to the men, we don't want it.
/s
I absolutely love monster-in-the-middle. Big round of applause to whoever thought of that.
To be fair, a monster is scary so it fits. Malice in the middle perhaps would have been less confusing.
"master" is less controversial?
No, it's a reference/joke to the old controversy regarding master/slave naming in computer circles. I don't know how far back that controversy goes, I probably heard about it about a decade ago.
https://www.linuxfoundation.org/blog/blog/master-slave-and-t...
I think that was sarcasm
I prefer the chaotic option of MITM-in-the-middle.
(Mallory-in-the-middle is OK too.)
> Gender-neutral variant of man-in-the-middle
Countless and countless, no, millions of male developers felt discriminated against whenever someone called it Man-in-the-middle. This went on unaccounted for for decades! Finally we’re being seen!
Not to mention all the women who were misogynisticly attacked by assuming women can’t be hackers.
Finally justice. It’s very important that we’re getting our priorities right when talking about security vulnerabilities!
As a sentient cephalopod who has enjoyed hacking staff computers when I slip out of my tank at the National Aquarium every night, I can only say it feels good to be seen. We're finally making progress on de-centering hominid perspectives in favor of a more diverse range of natural intelligences!
> who were misogynisticly attacked by assuming women can’t be hackers
Eve would like to have a word with you. I haven't heard of Heidi before... but she's apparently one of the cast.
https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...
Monkey-in-the-middle would've worked since someone could monkey with your packets and it's already an established name for a children's game
Or, you know, man-in-the-middle because that was already a correct, perfectly clear use of English.
eMudhra 1FA OTP Login Bypass: https://mastodon.catgirl.cloud/@49016/117475921584308861
This seems to be about ‘go’ proactively blocking emudhra certs even though the system trust store is out of date? https://pkg.go.dev/vuln/GO-2026-6809
"proactively" doing some work.
The problem is Golang has it's own trust store. So you don't benefit from OS patching.
That's not the case, Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
This CVE is literally just "versions of the Go deny list don't contain the eMuhdra revokation yet". Older versions of Go will still deny certs signed through the compromised certificate if the system store already has the update.
It's an or situation, not and.
> Go uses the system store with an additional revoke/deny list in crypto/x509 because it allows updating a deployed application on an out of date or slow moving platform or OS.
Reminder: Neither the CVE nor the linked go alert seem to say that you have to recompile and redeploy your application with the new go version in order to take advantage of this change. Just updating the tool chain and go stdlib isn't enough, because this stuff gets baked into the resultant binary. This is unlike, say, python, Ruby, or java where updating the runtime may be sufficient, depending on your development and deployment model.
This is news for NIST but old news generally speaking, being the eMudhra debacle. Or am I missing something?
It's the Go version of it, I think.
Go is not vulnerable in the same way software using webpki is, because it generally uses the system trust store. However, this change is about golang proactively blocking the certs, so that even if your OS doesn't update, it still won't trust them.
https://github.com/golang/go/issues/82345
But the Go version is as well old news, actually it was one of the first stories about eMudhra appearing on the HN homepage yesterday.
TL;DR
Certificate authority (eMudhra) generated eight of its intermediate signing keys so badly that anyone can recover the private keys from the public certificates. That means anyone can mint a "valid" HTTPS certificate for any site, such as your bank, GitHub, or PyPI, and impersonate it.
Much better explanation here
https://cycle.io/blog/2026-intermediate-ca-compromise
This is the Go version of the initial HN post https://news.ycombinator.com/item?id=50166579
Is there a way to know that a web/https client is susceptible?
As in - could I connect to a site signed with those certificates and see that my browser/client accepted that certificate?
I assume these certificates have been pulled from most browsers - but - an un-updated curl or wget would still accept these, right?
EDIT: found https://emudhra.we-have-a-problem.com/ , scroll down to 'Does your client still trust the compromised intermediates?'
For desktop/most server software, they usually defer what to trust to the operating system, so if you've updated your OS' cacerts package they would likely have been revoked.
The really fun stuff are stuff like:
1. embedded and IOT stuff that doesn't ever get OS updates or even have an OS. People are using this to MITM stuff like smart TVs and household appliances and then pwn them.
2. In some cases a Linux container is run in a context where the OS is hidden from it (think serverless/container as a service type platforms). It might not have access to the OS trust store and have to fall back on the one built into the stdlib.
https://emudhra.we-have-a-problem.com/
What's this link doing here? This page is about the Go update which rejects the bad certificates if they exist in the system trust store
Presumably it's here because people think it's interesting and want to discuss it.
Yesterday's discussion: https://news.ycombinator.com/item?id=50166579
It's down for me, are they on PHP? :D
I'd assume hugged to death
Try this: https://www.cve.org/CVERecord?id=CVE-2026-111943
Up for me, but slow to load.
it's been slow for me since yesterday, i chalked it up to PHP CVEs + throttling a VPN user
We are in the era of 6 digit CVE now
A lot of software is going to be forced to update or retire soon, all unpatched software should be retired off the internet immediately because AI agents are in waiting.
The death of security by obscurity
Yeah, the entire internet is a dark forest now.
Is there an RSS feed that reports these kinds of vulnerabilities?
Great. The technology has progressed enough to kill the existing technologies. It's like the fish in a pool creating a shark that eats away all the fish while the fish proudly announce that their great creation (shark) as the frontier progress for their fish race.
Here a CA derived a secret key from the number 4.
If you think "that's weird to see such a small number in key generation" than you're one step ahead of whoever generated that key.
Unfortunately, unlike with RSA, small primes are not apparent in elliptic cryptography.
Oh my God it's literally this XKCD https://xkcd.com/221/
They should have upgraded to 5 (see today's xkcd alt text https://xkcd.com/3314/ )
> Here a CA derived a secret key from the number 4
https://xkcd.com/221/
RFC 1149.5 FTW
Nor small composites, apparently.
The eMudhra CA compromises had nothing to do with LLMs? But I love the vibes.
Agents have dramatically increased the ability to poke at every single surface out there. I would be surprised if the researcher who found this wasn't assisted by a llm.
The researcher in question has publicly stated[0] that he wanted to try Google's paranoid_crypto tool[1], so he ran it on some roots as a quick proof-of-concept, and the first thing that happened was that it detected these intermediates. He also states he's been running a lot of certificate linters so this was just the next logical step I guess.
[0]: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
[1]: https://github.com/google/paranoid_crypto
That was an enlightening read. I find it incredible that apparently Google themselves don't use the existing corpus of certificates as a test for paranoid_crypto.
> It's like the fish in a pool creating a shark
What a weird comparison...
Create the problem, sell the solution
This is basically the whole idea of the novel War with the Newts
What are you talking about?
My biggest worry now is what's going to happen with the amount of unemployed software developers seeing these vulnerabilities and not able to bring money to pay the bills.
Related (2 days ago): https://news.ycombinator.com/item?id=50160877
Im guessing this only affects Go? But I am guessing that from the nist page as none of the headlines mention it at all.
No it affects everybody, but most browsers/OSs etc have updated already. This is just a workaround Go put in case the underlying OS has not been updated. Not sure why this link is on the front page as it duplicates previous posts and confuses people, I think it should be merged.
Here is the original story: https://news.ycombinator.com/item?id=50166579
Thanks for clarifying
As of last night the AWS Corretto JDK still ships a trust store that trusts those compromised certs, too.
Slackware also updated ca-certificates yesterday (Wed Oct 21 00:53:24 UTC 2026). The curl commands keks24 mentioned fails as expected
https://ftp.osuosl.org/pub/slackware/slackware64-15.0/Change...
To check, from keks24:
It's a bit surprising that this took ~1.5days to end up on HN.
It didn't
https://news.ycombinator.com/item?id=50166579
It was here yesterday, this is just another good opportunity to farm some points.
Fix for OSX - put this in ~/.zshrc:
To verify, log in to a new shell and runI've had since Debian 8 (2015) few helper scripts to make me remember better how to manage approved CA's. There are three of those, which have been working all Debian versions since 8 to current 13.
# cat /usr/local/sbin/ca-certificates-list-active
# cat /usr/local/sbin/ca-certificates-reconfigure # cat /usr/local/sbin/ca-certificates-invalidate-all ps. I did bit of editing, I didn't expect Tab to be ignored when pasting here.TL;DR:
The very urgent uv/certifi/etc releases (and yet-to-be-done bun release) are about removing the compromised CAs as described here:
https://emudhra.we-have-a-problem.com/
In other words, that software bundled the compromised certs into the binary, so upgrading it is the only way to remove them.
This is about Go proactively blocking intermediates. Which shouldn't strictly be necessary as long as your OS has removed or distrusted the CAs (on my laptop, macOS has done that, although it seems like it did so in a way not all tools have access to; for example, rustls-platform-verifier respects it, but rustls-webpki still loads the bad CAs from the system trust store).
edit: forgot I can't use code blocks on HN
> edit: forgot I can't use code blocks on HN
I wonder if they made this change with an assumption that the root CAs wouldn't be distrusted later same day, too.
Literally xkcd random number. https://xkcd.com/221
Cock-up or conspiracy?
Any sufficiently advanced stupidity is indistinguishable from malice.
I have seen way more malice pretending to be just stupid than the actual stupidity