#git command https remote is affected by the #brotli buffer overflow vulnerability CVE-2026-111497 since it enables compression support:
https://github.com/git/git/blob/7e34d8174dcda3435d1404c9a30bef46afe6c13e/http.c#L2284
https://github.com/git/git/blob/7e34d8174dcda3435d1404c9a30bef46afe6c13e/remote-curl.c#L980
Make sure to update brotli as soon as possible.
UPDATE: HTTP servers are only affected if configured to perform HTTP requests themselves and these requests support brotli compression. It is likely these settings don't affect that part.
If running #apache2 you probably want to update brotli as soon as possible or if not possible a2dismod brotli and restart apache2.
For #nginx you probably want to update brotli as soon as possible, too, and or if not possible disable it for now if enabled (brotli off;) and reload nginx.
In case of curl the silver lining is that by default curl / libcurl doesn't decompress the data. curl command only decompresses if requested with --compressed option and libcurl CURLOPT_ACCEPT_ENCODING defaults to NULL.
For some reason, the CVE-2026-111497 buffer overflow vulnerability in the #brotli decoder is mostly associated with #nodejs, but this is a far wider issue. Brotli compression is supported by many client-side applications processing HTTP responses. While some of them have sandboxes and a quick update cycle (read: web browsers), many don't. In particular, many devices and applications using #curl / libcurl are affected and must be updated ASAP.
https://github.com/advisories/GHSA-9v8h-qqgm-4m35
https://nvd.nist.gov/vuln/detail/cve-2026-111497
The week only keeps getting better... apparently, multiple not yet fixed Linux kernel vulnerabilities were disclosed by accident when they were posted to the public mailing list rather than the private one. Oops.
https://www.phoronix.com/news/LKML-New-Trend-Vulnerabilities
You can just drop the #eMudhra CA certificate to #mitmproxy and have fully trusted TLS MiTM right now - what a time to be alive...
https://docs.mitmproxy.org/stable/concepts/certificates/#the-mitmproxy-certificate-authority
This is rather impressive: a-ha's Take On Me recreated in a shader. With the song. With vocals. :mind_blown:
It's Friday, and we have 4 more local privilege escalation vulnerabilities disclosed for the Linux kernel:
- DirtyAH6 (CVE-2026-80844)
- TUNderflow (CVE-2026-81000)
- PPPoEject (CVE-2026-68121)
- DiagSpill (CVE-2026-74469)
"The underlying bugs have been around for 10-21 years. The first three LPEs require either unprivileged user namespaces or specific CAPs; DiagSpill does not."
https://www.openwall.com/lists/oss-security/2026/09/18/3
https://heyitsas.im/posts/lpe-quartet/
#CVE_2026_80844 #CVE_2026_81000 #CVE_2026_68121 #CVE_2026_74469
Sneak peek at some of the upcoming features of #MorphOS 3.22, namely making more of the system resources available:
https://www.youtube.com/watch?v=qZg5fTCapCU
Note that this isn't full SMP as it stands now.
Back when the "internet" involved expensive phone calls and modems, someone figured out that a video backup system (VBS) could be used to distribute hundreds of megabytes of "backups" between friends by shipping a VHS cassette in a padded envelope.
You just needed a VCR (everyone had one), and a small harness that could sample the video signal from the VCR for the software to decode.
Interestingly, the Video Backup System website is still up: http://www.hugolyppens.com/VBS.html
I'm sure someone used this thing for actual backup purposes as well...
No, the libssh2 vulnerability CVE-2026-55200 isn't end of the world.
1. You need to defeat ASLR to successfully exploit it. The PoC works only when you disable ASLR. In most realistic use cases you need additional off-band infoleak from the app using libssh2.
2. You also must somehow convince the victim to connect to your malicious server, OR compromise some existing server to perform the attack.
Calling this a "CRITICAL VULNERABILITY" is dumb.
I, for one, hail our EU overlords for staying their ground and not bending over to Apple.
This EU regulation did not come as a surprise to anyone, and definitely not to Apple. Yet they decided to go all knee-jerky about it.
Food for thought: If you cannot implement an AI feature in an interoperable and safe manner, it likely should not be implemented at all.
Regardless of alternate military systems being available, large regional jamming of GNSS would still cause significant disruption and global chaos.
Russian GPS jamming capability revealed https://www.youtube.com/watch?v=tz23G_UXCGA
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
All my attempts to communicate a vulnerability in #Signalapp have failed - I have not received any response to my multiple messages to them. Good people have tried to forward my concern to them (and I am thankful for your efforts and help), yet this has been to no avail.
I am disappointed in the lack of communication from Signal. I will be disclosing the full details of the issue later today (with end-user mitigations), after the six-month anniversary of the initial report.
Denmark has implemented this change now: https://www.nationalbanken.dk/en/news-and-knowledge/publications-and-speeches/other-publications/2026/status-of-the-card-payment-contingency-measure-in-denmark
Sweden should be done with the implementation by 1 July 2026: https://www.riksbank.se/en-gb/payments--cash/payment-preparedness/offline-payments/
Finland, Denmark, Norway, Sweden, and Estonia are soon enabling offline debit card payments for at least seven days without network connectivity. The change covers payments for essential goods in physical trade, such as food, medicine, and fuel. Each country has made - or is in the process of making - the required changes to their related regulations to enable it.
The motivation for this change is to enable payments even in exceptional situations such as network disruptions due to sabotage or conflict. TL;DR: You can pay for essentials even if Russia cuts the cables.
Plans for this change were announced in May 2025: https://www.reuters.com/business/finance/nordics-estonia-plan-offline-card-payment-back-up-if-internet-cut-2025-05-07/
#resilience #preparedness #infrastructure #payments #banking
