DEV Community: CodeWithRomi

Patch These Four Linux Kernel Local Root Vulns Now: DirtyAH6, PPPoEject, TUNderflow, and DiagSpill

CodeWithRomi — Wed, 07 Oct 2026 23:00:49 +0000

Four Linux kernel vulnerabilities went public on 18 September 2026, and they are the kind you should not sit on. DirtyAH6 (CVE-2026-80844), PPPoEject (CVE-2026-68121), TUNderflow (CVE-2026-81000) and DiagSpill (CVE-2026-74469) are all local privilege escalation bugs, meaning an attacker or malicious process with a foothold on your machine can escalate to root. Working proof of concept exploits for all four are public. If you are running Proxmox, a Raspberry Pi, or any self-hosted Linux node, this is a patching weekend.

Security researcher Asim Manizada reported the four bugs in mid July 2026 and published a technical write-up plus working exploits on 18 September 2026, after a coordinated hold so distributions could ship fixes first. The oss-security post and the accompanying write-up carry the per-CVE detail. Upstream, the earliest stable releases that contain all four fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Note that the 7.0 series reached end of life on 27 June 2026, so a 7.0 kernel only carries these fixes if your vendor backported them.

💡 Why This Matters for Homelabbers

Local root exploits are often dismissed as "low risk" because they require existing access. That framing misses the threat model for homelabs and self-hosted infrastructure. If any service you run gets compromised, a web app, an LXC container with a shared kernel, or even a rogue package, a local root bug turns that into full node ownership.

Proxmox LXC containers share the host kernel. A container breakout combined with a local priv-esc is a realistic attack chain. Raspberry Pi nodes running exposed services are in the same boat. Patch the kernel, then verify.

🧰 Prerequisites

SSH or console access to each node
sudo or root privileges
A maintenance window, since patching requires a reboot
Proxmox nodes: access to the Proxmox web UI or CLI for VM/container shutdown sequencing

🔧 Step-by-Step: Patching Your Nodes

Step 1: Check your current kernel version on every node so you know what you are starting from.

uname -r

Note this output. You will compare it after the update to confirm the new kernel is running.

Step 2: Update your package index and apply all available security updates. On Debian and Ubuntu based systems, including Proxmox and Raspberry Pi OS:

sudo apt update && sudo apt full-upgrade -y

On Proxmox specifically, you also want to pull from the Proxmox repositories. If you are on the no-subscription repo, this is already covered by the command above. Run pveversion -v afterward to confirm the Proxmox packages are current too.

Step 3: If you are running Raspberry Pi OS, check the kernel package by its current name. On Bullseye and earlier the kernel shipped in the raspberrypi-kernel package, but Raspberry Pi OS moved to Debian style linux-image-rpi-* packages with Bookworm, so on a current install you want linux-image-rpi-v8 or linux-image-rpi-2712 depending on the board. The apt full-upgrade command above will still catch it, but confirm with:

# Bookworm and newer
apt-cache policy linux-image-rpi-v8

# Bullseye and older
apt-cache policy raspberrypi-kernel

The "Installed" and "Candidate" versions should match after your upgrade. If they do not, run the upgrade again.

Step 4: Reboot to load the new kernel. This is not optional. The running kernel in memory is still the old one until you reboot.

sudo reboot

For Proxmox hosts, shut down or migrate your VMs and containers before rebooting the host. Use the Proxmox web UI or:

# List running VMs
qm list

# Shutdown a VM by ID
qm shutdown [vmid]

# List running containers
pct list

# Shutdown a container by ID
pct shutdown [ctid]

Step 5: After the reboot, confirm the new kernel is loaded:

uname -r

The version string should be newer than what you recorded in Step 1. Cross-reference it against your distro's security advisory to confirm the patched version is in place. For Debian, check security-tracker.debian.org. For Ubuntu, check ubuntu.com/security/notices. For Raspberry Pi OS, check the Raspberry Pi blog and release notes.

🛡️ Patch Status, Checked 29 September 2026

This is the part of the post that goes stale fastest, so here is a dated snapshot. Everything below was checked against the Debian security tracker, the Ubuntu CVE tracker and the Proxmox kernel changelog on 29 September 2026. Re-check before you decide you are covered.

Debian 13 trixie: all four first fixed in linux 6.12.111-1, shipped as DSA-6528-1.
Debian 12 bookworm: DirtyAH6, PPPoEject and DiagSpill first fixed in linux 6.1.187-1 from bookworm-security. TUNderflow is the exception. The Debian tracker still lists bookworm as vulnerable, 6.1.187-1 included, so there is no fix for CVE-2026-81000 on bookworm yet.
Ubuntu 22.04, 24.04 and 26.04: at the time of this check the Ubuntu CVE tracker showed no released kernel for any of the four on the main linux packages. They sit at needed or pending. Watch ubuntu.com/security/notices instead of assuming an upgrade fixed it.
Proxmox VE: the Proxmox kernel changelog names only TUNderflow, first fixed in proxmox-kernel-7.0 version 7.0.14-19, released 18 September 2026. The newest build at the time of checking was 7.0.14-20 from 24 September 2026. The other three CVEs are not named anywhere in that changelog, and the Proxmox 7.0 kernel follows the Ubuntu kernel, which has not released them, so do not assume DirtyAH6, PPPoEject and DiagSpill are closed on a Proxmox host. Run pveversion -v and compare against the changelog.
Raspberry Pi OS: no Raspberry Pi OS kernel build carrying all four fixes could be confirmed at the time of this check. On the 6.12 branch you need 6.12.109 or newer for the full set, so check the installed package version rather than assuming.

🛡️ What Each Vulnerability Affects

Here is what each bug actually is, taken from the disclosure and the researcher's write-up. Three of the four need CAP_NET_ADMIN in a network namespace the attacker controls, which an ordinary local user obtains by creating an unprivileged user namespace first. DiagSpill is the exception and needs no special privileges at all.

DirtyAH6 (CVE-2026-80844): The IPv6 Authentication Header code in the IPsec and XFRM path does not check that a routing header's segments_left field is no larger than the number of addresses actually present, so pointer arithmetic in ipv6_rearrange_rthdr() walks out of bounds and an oversized memmove() corrupts kernel memory. It needs AH6 and XFRM support plus CAP_NET_ADMIN and CAP_NET_RAW in a namespace the attacker controls. The researcher also reports a remote crash, and in his own lab remote root, against a host acting as an IPv6 router that applies AH in transport mode.
PPPoEject (CVE-2026-68121): A use after free in pppoe_sendmsg(). The function holds a pointer into the socket buffer head across a dev_hard_header() callback that can reallocate that head, then writes six bytes through the stale pointer. It needs a lower device whose header callback expands the buffer head, not merely a loadable PPPoE module, which makes it the narrowest of the four in practice.
TUNderflow (CVE-2026-81000): The TUN/TAP driver stores a receive headroom value without bounding it. A device path that propagates oversized headroom (the proof of concept chains a netkit device through Open vSwitch to a raw TUN port) underflows a size calculation and leaves packet data 64 bytes past the end of the allocation. Simply having a TUN or TAP interface is not enough, you need that headroom propagation path. Worth correcting a common assumption here: Docker's default bridge networking uses veth pairs rather than TUN/TAP, and the in kernel WireGuard module is its own device type, so the usual homelab exposure is QEMU tap interfaces and OpenVPN style TUN devices, not containers.
DiagSpill (CVE-2026-74469): An SCTP association can hold up to 65,536 peer transports but the counter is 16 bits wide, so it wraps to zero at the limit. sctp_diag then reserves buffer space based on the wrapped count and copies the full transport list anyway, writing roughly 8 MiB past the end of the response buffer. This one needs no capabilities and no user namespace, only SCTP and sctp_diag support, which is what makes it the priority of the four.

DiagSpill is the one to move fastest on if you are triaging. It is the only one of the four that an ordinary local user can reach without creating a user namespace, which also means the usual advice to restrict unprivileged user namespaces does nothing for it. If you do not need SCTP, keep the module out of the kernel.

🛡️ Hardening Beyond the Patch

Patching is the fix, but a few additional controls reduce your exposure, which matters more than usual here because some distributions have not shipped all four yet. Restricting unprivileged user namespaces closes the ordinary user path to three of the four. It does nothing for DiagSpill.

Restrict unprivileged user namespaces: Three of these four bugs need a user namespace for an ordinary local user to reach them. Ubuntu introduced AppArmor based restrictions in 23.10 and enabled them by default from 24.04, controlled by kernel.apparmor_restrict_unprivileged_userns, so 24.04 and 26.04 are covered out of the box. Debian is not. The Debian and Ubuntu specific kernel.unprivileged_userns_clone knob has been discussed for deprecation, so confirm it exists on your kernel with sysctl -a | grep userns before relying on it; the portable upstream equivalent is sysctl -w user.max_user_namespaces=0. Either way you will break things that legitimately use user namespaces, including Flatpak, rootless containers and browser sandboxes.
Use AppArmor or SELinux profiles: Proxmox ships with AppArmor. Make sure it is enforcing for your LXC containers. Unprivileged containers with AppArmor confinement are significantly harder to break out of.
Limit local access: Do not run untrusted code or expose shell access to untrusted users on these nodes. Local privesc only matters if someone or something local can trigger it.
Unload unused kernel modules: If you are not using PPPoE or SCTP, keep both out. Add blacklist pppoe and blacklist sctp to a file in /etc/modprobe.d/ and run update-initramfs -u. Blacklisting stops the on demand autoload that a socket call would trigger, and for DiagSpill that is the only mitigation short of patching, since restricting user namespaces does not touch it. Verify with lsmod | grep -E 'pppoe|sctp' afterwards.

🔧 Troubleshooting

Kernel version did not change after reboot: Your package manager may have the patched package available but it was not installed. Run apt list --upgradable | grep linux-image to check, then install explicitly with sudo apt install linux-image-[version] matching your architecture.

Proxmox node is stuck on an older kernel: Proxmox sometimes pins the kernel for stability. Check /etc/default/grub and the GRUB menu to ensure the new kernel is selected as default. Run update-grub after confirming the package is installed.

Raspberry Pi will not boot after upgrade: This is rare but can happen if the bootloader and kernel fall out of sync. Boot from a backup SD card or use rpi-update with caution, and check the Raspberry Pi OS forums for your specific board and OS version before using it.

✅ Wrap Up

Four local root bugs in one disclosure batch is a bad day for Linux security. Updating and rebooting is the right move, but as of 29 September 2026 it is not the whole answer: Debian trixie has all four, Debian bookworm is still missing the TUNderflow fix, and Ubuntu has not released kernels for any of them. Prioritize DiagSpill, since it is the one an unprivileged local user can reach without a user namespace, and check the tracker for your distribution instead of assuming a fresh upgrade covered you.

After you patch, take five minutes to check your other nodes. It is easy to forget a Raspberry Pi tucked behind the TV or a secondary Proxmox node you set up months ago. Cross-reference the patched kernel version against your distro's security tracker to make sure you are actually covered, not just up to date on packages.

Stay subscribed to oss-sec if you want these disclosures in your inbox before they make the rounds on aggregators.

Related from the lab

Originally published at codewithromi.com.

WordPress 7.1.2 Patches a Critical Path Traversal to RCE: Update Now

CodeWithRomi — Wed, 07 Oct 2026 23:00:46 +0000

A serious vulnerability was disclosed in the WordPress core codebase: an unauthenticated path traversal bug that, under the right server conditions, can escalate to remote code execution. That combination, no login required plus potential RCE, puts this near the top of the priority list for any WordPress site owner or host. Here is what the vulnerability is, who is affected, and exactly what to do about it.

💡 Why This Matters

Path traversal vulnerabilities let an attacker reference files outside the intended directory by injecting sequences like ../ into a request. On their own they are dangerous. Chained with a code execution primitive, they become critical.

The "conditional" part of this disclosure means RCE is not guaranteed on every WordPress install. Server configuration, PHP settings, and installed plugins or themes all influence whether the traversal can be weaponised into execution. But "conditional" does not mean "safe to ignore." Attackers will probe for the conditions that make it work, and many shared hosting and default VPS setups are likely to qualify.

The advisory is GHSA-7hp8-65ch-5whp in the WordPress develop repository, and it is CVE-2026-87902, rated Critical at CVSS 4.0 9.2. Every release from 4.7.0 through 7.1.1 is affected. WordPress shipped 7.1.2 on 22 September 2026 along with backports to every branch still eligible for security fixes, down to 4.7.37. Treat this as urgent rather than theoretical: CISA added CVE-2026-87902 to its Known Exploited Vulnerabilities catalog on 25 September 2026, and public scanning tooling plus attempts to write PHP files through pearcmd.php are already being seen in the wild.

🧰 Prerequisites: Who Should Read This

Anyone running a self-hosted WordPress site on 4.7.0 or later, which in practice means anyone running WordPress
Hosting providers and managed WordPress hosts
Homelab builders running WordPress internally (yes, even private sites)
DevOps teams with WordPress in staging or CI pipelines

If WordPress is running somewhere you control, this post is for you.

🔍 How the Vulnerability Works

The flaw is in one specific thing: page template resolution. An unauthenticated request can steer get_page_template() into including a chosen readable local .php file from outside the active theme's directories. That makes it a local file inclusion rather than a generic web root escape, and it is classed as CWE-98, improper control of filename for an include or require statement.

The conditions are narrower and far more specific than 'a misconfigured server', and they are worth checking against your own install rather than guessing. The file inclusion needs the active theme, parent or child, to contain a top level directory whose name begins with page-. That is not exotic: page-templates/ ships in Twenty Twelve and Twenty Fourteen and in popular themes including Neve, Hestia and Sydney. Turning that inclusion into code execution needs two more things: a readable .php file on the server that will act on attacker supplied arguments, in practice pearcmd.php, and register_argc_argv set to On. Official PHP Docker images and default cPanel configurations on PHP before 8.5 both qualify. For the precise code path, refer to the official security advisory.

🛠️ Step-by-Step: Patching Your WordPress Install

The most important action is updating WordPress core. On the current branch that means 7.1.2. If you are held back on an older branch there is a backport for it, 7.0.6, 6.9.9, 6.8.10, 6.7.9 and so on all the way down to 4.7.37, so being unable to move to 7.1 is not a reason to stay unpatched. Here is how to update cleanly.

Step 1: Back up your database and files before touching anything.

# Example using WP-CLI to export the database
wp db export backup-$(date +%F).sql --allow-root

Step 2: Update WordPress core via WP-CLI (recommended for server installs).

wp core update --allow-root
wp core version --allow-root

Step 3: Confirm the installed version matches the patched release listed in the advisory.

wp core version --allow-root

Step 4: If you manage WordPress through a hosting dashboard (cPanel, Plesk, Kinsta, etc.), use the built-in one-click updater or auto-update toggle. Confirm the version number in the WordPress admin under Dashboard, then About.

Step 5: Enable automatic background updates for minor releases if you have not already. Add this to your wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

This ensures security patches ship automatically without waiting for manual intervention.

🛡️ Hardening: Reduce the Attack Surface Regardless of Version

Patching fixes the specific bug. Hardening reduces the blast radius of the next one.

Block PHP execution in the uploads directory. Worth doing, but be clear that it does not mitigate CVE-2026-87902, which includes a .php file already present on the server rather than one an attacker uploaded. Keep it as general hygiene against the next upload driven bug. For Nginx, add this to your server block:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

For Apache, drop a .htaccess file inside wp-content/uploads/:

<Files "*.php">
    Require all denied
</Files>

Disable file editing in the WordPress admin. Add to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Break the RCE preconditions if you cannot patch within the hour. Set register_argc_argv = Off in your PHP configuration and confirm it with php -i | grep register_argc_argv. Then check whether a reachable pearcmd.php exists at all, with find / -name pearcmd.php 2>/dev/null, and remove it if nothing on the box needs PEAR. Neither of these closes the file inclusion, but together they remove the documented route from inclusion to code execution. Patching is still the fix.

Run WordPress behind a WAF. Cloudflare, Wordfence, or a self-hosted option like ModSecurity can catch traversal patterns at the request layer before they reach PHP. Even a free Cloudflare plan adds meaningful filtering.

Restrict xmlrpc.php and wp-login.php by IP if possible. Unauthenticated attack surface shrinks dramatically when admin endpoints are IP-locked.

# Nginx example: restrict wp-login.php
location = /wp-login.php {
    allow [your-admin-IP];
    deny all;
}

🔧 Troubleshooting Common Update Issues

WP-CLI command not found: Install it by following the official WP-CLI installation guide at wp-cli.org. On most Linux servers it is a single curl download and chmod.

Update fails due to file permissions: WordPress needs write access to its own directory during updates. Check that the web server user (often www-data on Ubuntu/Debian) owns the WordPress files.

chown -R www-data:www-data /var/www/html/

Site breaks after update: Restore from the backup taken in Step 1, then investigate plugin or theme conflicts. Deactivate all plugins and retest. The WordPress support forums and the WP-CLI --debug flag are your friends here.

Managed host shows no update available: Some managed hosts patch at the server level before surfacing a WordPress core update. Contact support to confirm your environment is running the patched version.

✅ Wrap Up

Unauthenticated path traversal leading to conditional RCE is the kind of vulnerability that gets actively exploited fast, especially against WordPress given its enormous install base. The fix is straightforward: update core to the patched release, turn register_argc_argv off if nothing on the server needs it, and put automatic minor updates on so future patches land without delay.

The patched version is 7.1.2, or the backport for whichever branch you are on. The official advisory (GHSA-7hp8-65ch-5whp) has the full backport list and the code path. Patch first, harden second, and since this one is already on CISA's exploited list, check your access logs for requests carrying page- template names or pearcmd while you are in there.

Related from the lab

Originally published at codewithromi.com.

Miri Was Leaking CI Secrets Through GitHub Actions Caches: What to Clean Up

CodeWithRomi — Wed, 07 Oct 2026 23:00:44 +0000

CI/CD pipelines are a common attack surface, and most developers focus on the obvious risks: exposed tokens, world-readable repos, overly permissive workflow permissions. But a subtler class of vulnerability comes from caching, and in September 2026 the Rust project published an advisory that is a textbook case. Miri, Rust's interpreter for detecting undefined behavior, was writing every environment variable it saw into the target/ directory. Cache target/ in GitHub Actions, as most Rust projects do, and any secret handed to that job was sitting in the cache where a later pull request run could restore it and read it.

The good news first, because it changes how you should read the rest: this is fixed. The Rust project published the advisory on 21 September 2026 and the nightly toolchain dated 22 September 2026 stops Miri persisting arbitrary environment variables, keeping only CARGO_* (excluding CARGO_*_TOKEN) and OUT_DIR. No CVE was assigned. What is left for you is cleanup rather than defense: update the toolchain, delete the caches you already have, and rotate anything that was in scope. This post covers the mechanism, that cleanup, and how to stop caching biting you again.

💡 Why This Matters

Miri runs Rust programs in an interpreted environment so it can detect undefined behavior at runtime. To notice when something build relevant changed between runs, cargo miri recorded the environment it was invoked with, and it recorded all of it rather than only the variables it needed. That record lived inside the target/ directory. Note what is not required here: nothing in your code, your test output or your logs had to mention the secret. Passing it to the step was enough for it to land on disk in the directory everyone caches.

That matters because of how GitHub Actions cache scoping works. A workflow run can restore caches created on its own branch and on the default branch, so a pull request run can pull back a cache that a privileged push to main created. The advisory spells out the conditions: you are affected if you run cargo miri in CI, pass secrets as environment variables to that step, cache the target/ directory with something like actions/cache or Swatinem/rust-cache, and allow pull requests to read from that cache.

The broader lesson goes beyond Miri. Any tool that snapshots its invocation environment into a build directory is a candidate for this class of bug, and build directories are exactly what CI caching is pointed at. Rust's toolchain is just where this instance was caught, reported and documented.

🧰 Prerequisites

A GitHub Actions workflow that uses Miri (typically via cargo miri test)
Familiarity with the actions/cache action or the built-in Cargo caching patterns
Repository secrets configured in Settings, such as API keys or tokens passed to your test environment

🔍 How the Leakage Path Works

Here is the setup that creates the risk. A workflow injects a secret as an environment variable, runs Miri, and caches the Cargo target/ directory to speed up future runs. The target/ directory is the part that matters. Caching the registry or the Miri sysroot was never the problem.

# Vulnerable pattern (simplified)
- name: Run Miri
  env:
    MY_SECRET: ${{ secrets.MY_SECRET }}
  run: cargo miri test

- name: Cache build output
  uses: actions/cache@v4
  with:
    path: target
    key: miri-${{ runner.os }}-${{ hashFiles('**/Cargo.lock') }}

The value of MY_SECRET does not have to appear in any log or test result. cargo miri persisted it into target/ as part of the environment snapshot, and the cache step then packaged target/ up. The next job or pull request run that restores this cache has a file containing your secret, without that secret ever being granted to the run.

No exotic trigger is required. You do not need a panic, a crash, or verbose diagnostics. Passing the secret to the step and caching target/ is the whole bug. The advisory also notes that someone who lifted a secret this way could push further commits to cover their tracks, so a clean-looking workflow log is not evidence you were fine.

🛡️ Step-by-Step: Hardening Your Pipeline

Step 1: Never inject production secrets into Miri test runs. If your tests genuinely need a credential, use a scoped, revocable test credential with no real permissions. Treat anything Miri can see as potentially loggable.

# Prefer a dummy or scoped value for Miri runs
- name: Run Miri
  env:
    MY_SECRET: "dummy-value-for-miri"
  run: cargo miri test

Step 2: Fix your caching scope. The directory that leaked is target/, so either stop caching it on jobs that see secrets, or stop giving those jobs secrets. If you do cache something for Miri, cache the sysroot, and use a distinct cache key so a Miri cache never collides with a standard build cache.

- name: Cache Miri sysroot only
  uses: actions/cache@v4
  with:
    path: ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib
    key: miri-sysroot-${{ runner.os }}-${{ hashFiles('rust-toolchain.toml') }}

Check the exact sysroot path for your toolchain with rustc --print sysroot rather than hardcoding it. The path above is illustrative; confirm it in your environment.

Step 3: Restrict workflow permissions explicitly. Add a top-level permissions block to limit what a workflow can do even if a cache is poisoned.

permissions:
  contents: read

Step 4: Isolate Miri jobs from secret-bearing jobs. Use separate jobs so the job running Miri never sees a real secret. GitHub Actions does not share environment variables across jobs unless you pass them explicitly, so inject secrets at the step level in the job that actually needs them. One correction worth making if you copy patterns off the internet: secrets: inherit is only valid on a job that calls a reusable workflow with uses, not on a job that runs its own steps.

jobs:
  miri:
    runs-on: ubuntu-latest
    # No secrets injected here
    steps:
      - uses: actions/checkout@v4
      - run: cargo miri test

  deploy:
    runs-on: ubuntu-latest
    needs: miri
    env:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - run: ./deploy.sh

Step 5: Audit your cache keys and paths regularly. Run a search across your workflow files for any actions/cache or cache-dependency-path usage that overlaps with paths your secret-injected steps write to.

grep -r "actions/cache" .github/workflows/

🔧 Troubleshooting

My Miri tests need real environment values to run correctly. Refactor the tests to accept injectable fakes, or use a secrets manager that vends short-lived credentials scoped only to the test run. This is a design problem as much as a security one.

I am not sure what is in my cache. Download a cache artifact locally using the GitHub CLI (gh cache list and gh cache download) and inspect the contents before assuming it is clean. The official GitHub CLI docs cover the exact flags.

We use a third-party caching action, not actions/cache. The same principles apply. Check whether that action stores artifacts in a location your Miri run can write to, and review the action's own permissions model.

✅ Wrap Up

Caching is one of the best levers you have for speeding up CI, but it introduces a persistent artifact that outlives a single workflow run. In this case the artifact was the ordinary Cargo target/ directory, and the tool filling it with secrets was doing so as a convenience feature. Be deliberate about what goes into the cache and which jobs hold real secrets.

Concretely, for this advisory: move to a toolchain from 22 September 2026 or later, delete the existing caches on any repository that ran cargo miri with secrets in scope, and rotate those secrets. Then, as standing practice, keep Miri jobs secret free, lock down workflow permissions, and audit your cache paths as part of any security review. Treat cached artifacts with the same suspicion you would treat a shared filesystem.

The primary source is the Rust project advisory GitHub Actions leaking secrets when Miri output is cached, published 21 September 2026. Read it in full for the exact affected conditions and for any follow-up, and pair it with the GitHub Actions security hardening guide in the GitHub docs.

Related from the lab

Originally published at codewithromi.com.