Last Week in AppSec for 15. January 2026

In this edition of Last Week In AppSec, the theme is “dev tooling”:

• The Sigstore cosign system fails to properly validate signature audit log, reducing safety
• The pnpm package manager is missing some important integrity checks on remote dependencies in lockfiles
• n8n, a popular AI-driven automation platform, struggles with webhooks complexity, leading to authorization bypasses and even an RCE

Sigstore Cosign patches bug that would allow audit log spoofing

The Sigstore system uses a cosign tool to generate and check signatures, allowing consumers of applications and components to verify the integrity by both checking that a signature is valid verifying an audit log. Versions of cosign 2.6.x (prior to 2.6.2) or 3.0.x (prior to 3.0.4) would verify integrity even when the Rekor audit log didn’t have a complete association to the signature it was checking.

Essentially, this lowered the difficulty for attackers to create forged signatures. An attacker would still need to compromise a legitimate maintainer’s identity and signing keys, though, so there’s no cause for panic.

Still, the “Rekor” component of Sigstore that provides audit logging is an important part of Sigstore’s strength. It raises the difficulty of some kinds of signature forging by providing an immutable log: think of it as a sort of “notary public” for the signing of artifacts. So if you’re relying on cosign to verify containers, binaries, and so on? You should make it a priority to make sure you’re using an up-to-date version.

In summary, I recommend:

• if you’re using cosign to verify things prior to builds or deployments, place a high priority on making sure you’re using a patched version. For most organizations, this isn’t a “drop everything and patch” scenario, but make sure it happens promptly!
• if you’re using Sigstore – the public repository or your own private one – for artifact signing, you should check the Rekor entries for your packages to make sure they’re correct. If you see one that’s missing key IDs, metadata, etc. then you may have been attacked and you should start a response.

Supply chain integrity protections in pnpm can be bypassed

If you’re using pnpm to manage your JavaScript/TypeScript dependencies, and you use its remote dependency feature (which allows you to pull libraries your app uses from a .tgz tarball file [or similar] on a web server at a URL the developer specifies), you should pay attention to this one.

Essentially, the pnpm tool doesn’t require there to be any integrity data in its lockfiles, which means that if an attacker managed to do anything to serve an unexpected tarball to you, you’d have no protection. An attacker could do this in many ways, such as compromising the web server, compromising a DNS record(s) to point to a server they control, and so on.

Starting with version 10.26.0, pnpm now computes integrity hashes for these remote dependencies, and checks them on installation. If an attacker replaces a legitimate tarball with something malicious, this should stop the installation. But, importantly, after you patch, you must regenerate and commit new lockfiles; lockfiles generated with older pnpm versions will still work, but they won’t have the integrity protection in place, leaving you vulnerable.

Mitigation is possible, but painful. If you can’t update pnpm, you should:

• stop using the feature (good luck if it’s adopted widely in your org, though)
• or sandbox your builds and use secondary integrity systems to monitor fetched dependencies

The risk here is, thankfully, low for most organizations. But if you have open-source projects that accept PRs from the public and use pnpm, this is urgent to address. And in that case, don’t just upgrade pnpm. Add a mandatory check to your PR rules, before running pnpm, that looks at ppm-lock.yaml and stops the build if it finds a pattern like this:

remote-dynamic-dependency@http://example.com/pkg.tgz:
  resolution: {tarball: http://example.com/pkg.tgz}
  version: 1.0.0

The safe version of that looks like:

remote-dynamic-dependency@http://example.com/pkg.tgz:
  resolution:
    tarball: http://example.com/pkg.tgz
    integrity: sha512-....STUFF....
  version: 1.0.0

That is, if you don’t have the resolution.integrity field for a remote dependency, you should break the build.

AI workflow automation tool n8n experiences “ni8mare”: unauthenticated file access

One of the most useful features of n8n is its ability to use webhooks to initiate actions and move data between various components. Unfortunately, there’s a pretty nasty weakness in some of those flows.

The folks at Cyera have an excellent technical deep dive into this issue, so I’ll just give you the highlights: an attacker can send a request to a webhook that expects a file upload, tamper with the Content-Type header, and trick that webhook into accessing files on the server. And with some care, this potentially allows the attacker to deploy and execute code remotely, which makes this CVE a potential RCE (Remote Code Execution).

Now, you can do a lot to mitigate this, including not exposing n8n webhooks to the public Internet (yes, I still capitalize it, even if that shows my age). But if you must, then you really have to either work to update this or, if you can’t, add some validation on your edge devices (though this is… challenging to maintain, so it’s probably easier to just embrace the upgrade pain).

• If you expose n8n webhooks to untrusted networks, patch now.
• Otherwise, make sure you don’t delay too much, and ensure you’re closely watching related infrastructure for signs of attack or compromise.

I want to point out that the organization behind the n8n product has a reputation for maintaining an outstanding security practice; but this goes to show that there’s no such thing as a perfect AppSec program.