kro

Only 1.31.0 and 1.31.1 are affected.

These commits [1] are related to the issue. I am not too familiar with the code, but it appears nginx manages/closes streams in a pool at times the attacker cannot control, and during short windows, it is vulnerable.

[1]:

https://github.com/nginx/nginx/commit/ceccdbd2ee799d020a371b...

https://github.com/nginx/nginx/commit/9e293766e73c469c015df5...

I did that for a while because of compatibility issues with a newer laptop, it works but generally if there is no reason it's way easier to stay with the provided packages. Compiling weekly due to security patches becomes annoying over time for no real gain other than the version number

mysql/maria also lets you turn off/down the isolation level for queries if you know the guarantees aren't needed, to speed things up. I think postgres does not have that option.

I've been receiving loads of spam from google MX servers lately until blocking all mails with X-Google-Group-Id headers. I don't know how it's possible, the contents were 100% spammer controlled, no Google template

You are correct.

Reminds me, we once got a letter by a German government body requesting some data exports from our company, and to upload them on findrive-ni.de

It turned out to be legit, but it's neither a subdomain of the state of Niedersachsen domain nor referenced in their official sites.

That also often shoots you as when json_encoding it only becomes an array when ordered "correctly" (numeric 0-based keys without gaps), otherwise an object. So to be safe you generally need to array_values after filtering. If in your testdata you only remove elements from the end you don't catch that before production data hits.

To get the first element there also is reset().

I love PHP though.

Sounds good - which software supports this? Specifically I'd prefer if it would do a composite key derivation in-time rather than "just a pw prompt but TPM has the full key"

Ubuntu also released TPM based FDE a few versions ago. I had these thoughts then and decided against using it. Typing my passphrase on boot is muscle memory and gives me simple security I can trust.

Also can recover data without my mainboard.

Maybe a hybrid (secureboot-TPM+phrase) slot for day to day to also prevent against evil maid attacks, and another slot with a backup passphrase would be acceptable.

No remotely reachable vuln should be taken lightly.

At the moment though, the preconditions look odd. I've been using nginx in various constellations for 10 years and never once combined rewrite and set.

However, some privs can be gained in namespaces/unshare.

It says coordinated distro release today, and I've received a notice earlier today but that does not include the CVE number. That's confusing / does not seem very coordinated to release 2 separate security update notices in a day.

https://lists.debian.org/debian-security-announce/2026/msg00...

Next easy attack vector is (non-rootless) docker run with rootfs mount, many are in docker group even when sudo is protected. Also, most sensitive data is in the user scope anyways (on a PC).

You should always run dev stuff in containers to start with. And when your system is compromised, reprovision from a higher scope, too many places to hide backdoors

So far all the information suggested to disable esp and rxrpc modules.

This bulletin suggest that more modules are necessary for complete mitigation

Containers, even with root user, are often stripped of these capabilities unless --privileged

VPN usage increased, but how to they draw the conclusion that this is children. I think it's more likely that adults are using VPNs to not have to deal with the ID process. I would do that.

As VPNs usually cost some money, which is already a barrier for minors.

CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.

It's scary to think that some day it will be more than a local attack vector. I don't want to imagine the fallout from a remote rce via tcp/ip.

These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer.

It's quite different from PATH-injecting an already privileged user.

Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily.

It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix security isn't perfect, but it should not allow this.

Maybe it would be reasonable for sysadmins to proactively whitelist used / block all exotic unused modules that are not needed in their system configuration.

This would reduce the amount of ring 0 code. But I've never seen such advice.

That is true, but if at least the widely used ones would get notified before that would be beneficial. If they have a responsible security contact point.

- Debian

- Ubuntu

- Arch

- Amazon/Azure

- Fedora/RHEL

Major os vendors will publish pages with the fixed versions:

https://security-tracker.debian.org/tracker/CVE-2026-31431

https://ubuntu.com/security/CVE-2026-31431

Also, disabling algif_aead is suggested as mitigation

This can likely be shipped as binary code without dependencies like python, as the bug is in the kernel.

Young people setting up a MITM and getting deeper into tech rather than consuming short-form-content is something I'd appreciate as a nice bonus effect.

Of course the EU solution isn't perfect and there are bypasses (there will always be and have always been), but let's appreciate it that way rather than too many PII, if it must come. I'd prefer the Age/RTA header and parental responsibility too.

Hetzner normally advertises their hardware servers as 2x 1 TB SSD, because it's strongly recommended to run them in SWraid1 for net 1TB. (Their image installer will default to that)

Once the first SSD fails after some years, and your monitoring catches that, you can either migrate to a new box, find another intermediate solution/replica, or let them hotswap it while the other drive takes on.

Of course though, going to physical servers loses redundency of the cloud, but that's something you need to price in when looking at the savings and deciding your risk model.

And yes, running this without also at least daily snapshotting/backup to remote storage is insane - that applies to cloud aswell, albeit easier to setup there.

Nginx mainline 1.29.x supports it. So once you get that and also the openssl version on your system, good to go. Likely too late for ubuntu 26.04, maybe in debian 14 next year, or of course rolling release distros / containers.

But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there. The real benefits are on huge cloud hosting platforms.

The URL does not even need to change, you can pushState with just a JavaScript object, catch the pop and do something like display a modal. (I use this pattern to allow closing fullscreen filter overlays the user opened)

Still, requires user interaction, on any element, once. So the crawler needs to identify and click most likely the consent/reject button. Which may not even trigger for Googlebot.

So they likely will rely on reports or maybe even Chrome field data.

It's a valid question how they detect it. As there are valid usages, just checking for the existence of the function call would not be correct.

These sites likely pushState on consent actions so it appears like any user interaction.

It's very very unlikely to get collisions there, but still not impossible. Whenever you map data of arbitrary length (infinite possibilities) to a limited length collisions are possible.

I wonder, what is the impact of this to widely deployed smartcards like credit cards / EID passports?

Aren't they relying on asymmetrical signing aswell?