#Debian trixie and bookworm now have the fix to libbrotli1

https://lists.debian.org/debian-security-announce/2026/msg00498.html

#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.

https://github.com/advisories/GHSA-9v8h-qqgm-4m35

#infosec #cybersecurity #CVE_2026_111497

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

#infosec #cybersecurity #CVE_2026_111497

ICEYE and Nokia partner with The Ministry of Defence of Ukraine to develop sovereign satcom capability. Having partners deliver intel is good, but having the capability to collect it yourself is even better - and more reliable.

https://www.iceye.com/newsroom/press-releases/iceye-and-nokia-partner-with-the-ministry-of-defence-of-ukraine-to-develop-sovereign-satcom-capability

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

#infosec #cybersecurity

Now the option to sign certificates with #eMudhra CA is built into #mitmproxy directly: https://github.com/mitmproxy/mitmproxy/pull/8500

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

#pentesting #cybersecurity #infosec

I'm having hard time trying to think of something as bad as this flaw.

Debian ssh key predictable random number generator (CVE-2008-0166) or heartbleed (CVE-2014-0160) comes to mind.

The long term impact of this #eMudhra intermediate CA cert private key disclosure: It is now possible to perform TLS MiTM to millions and millions of older #IoT devices (or other devices that won't or can't get updated). The root certificate that has signed the affected intermediate certificate was added to trust stores in about beginning of 2019 (*). It expires only in 18-feb-2043.

This opens the avenue for all kinds of nasty things.

*) https://bugzilla.mozilla.org/show_bug.cgi?id=1442337

#infosec #cybersecurity

Mitigating CVE-2026-111943 on #Debian:

- sudo dpkg-reconfigure ca-certificates
- Select "ask" and deselect the following entries:
mozilla/emSign_ECC_Root_CA_-_C3.crt
mozilla/emSign_ECC_Root_CA_-_G3.crt
mozilla/emSign_Root_CA_-_C1.crt
mozilla/emSign_Root_CA_-_G1.crt
- Hit <Ok>

Alternatively you can edit /etc/ca-certificates.conf manually and add the specific entries:

!mozilla/emSign_ECC_Root_CA_-_C3.crt
!mozilla/emSign_ECC_Root_CA_-_G3.crt
!mozilla/emSign_Root_CA_-_C1.crt
!mozilla/emSign_Root_CA_-_G1.crt

...and sudo update-ca-certificates

#CVE_2026_111943

You peeps remember when it was a big deal that #CVE ID format would have to be changed because more than 9999 vulnerabilities would get reported per year?

Simpler times, eh…

https://www.cve.org/Resources/Media/Archives/OldWebsite/data/board/archives/2007-01/msg00000.html

#infosec #cybersecurity

#Debian [DSA 6528-1] linux kernel #security update has fixes to 1313 CVEs.

https://lists.debian.org/debian-security-announce/2026/msg00441.html

Shitrix

I'll get my coat.

#Erlang changing the language in a way that breaks existing code depending on which Erlang version you have installed is somewhat off-putting. The issues around triple-quoted strings (EEP-0064) come to mind as "fine" example of this.

I will NOT send photo of my ID to anyone. Goodbye #hackerone

I see #Microsoft has invented Time Machine ("Point-in-time restore"). https://learn.microsoft.com/en-us/windows/configuration/point-in-time-restore

Naturally this being Microsoft it's full of all kinds of risks, limitations and known issues.

#Microsoft #SNDS is sending re-attest requests with bogus dates.

"Deadline: Sun, 28 Oct 0001 03:00:00 GMT"

I'll try my best to make it by that deadline.

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