Last Week in AppSec for 08. January 2026

In this edition of Last Week In AppSec, we have a host of vulnerabilities along with a few other items of note:

1. Changes to the series for 2026,

2. React2Shell exploitation continues,

3. Shai-Hulud 3.0 turns out not to be a thing,

4. MongoBleed leaks secrets from MongoDB servers,

5. The AdonisJS web framework struggles to handle multipart form data (arbitrary file write),

6. The RustFS distributed object store hardcodes a gRPC token leading to auth bypass

Changes to the Last Week In AppSec series for 2026

I started writing this series last year as an experiment and learned quite a bit. Based on reader feedback and a handful of other factors, there will be a few changes to it in 2026, and a few things that will stay very much the same:

• The feature will publish on Thursdays rather than early in the week

• I’m removing the constraint of only talking about things that didn’t get attention. I’ll still look for those, but the focus will be on things that are interesting and impactful for defenders.

• I’m still not going to use AI to write or edit. However, I will use AI tools in a targeted way to make educated guesses. AI-produced content will be highlighted like so (for “view source” nerds: `<mark class=”ai-content”>`), or otherwise unambiguously labeled. The “feature images” on each article are all AI-generated illustrations.

• I’m going to make an effort to have more detailed information about vulnerability advisories we cover in the series, making sure to include at-a-glance information that’s critical for defenders. This will evolve as the year goes on, and will probably be ugly: I’m a researcher, not a designer 😉

• There will be weeks when it doesn’t make sense to publish Last Week In AppSec, and I just… won’t. If I’m on vacation, if there’s a large incident in the industry that I’m helping Checkmarx customers navigate (*cough* Shai-Hulud *cough*), etc. then it might just get skipped without comment.

I’m looking forward to continuing to do this in 2026, and I hope you’re looking forward to reading!

React2Shell exploitation just keeps on going

The React2Shell vulnerability from 03. December 2025 remains persistent, and is being actively exploited as Google reported on 12. December. Payloads observed include:

• MINOCAT
• SNOWLIGHT
• COMPOOD
• HISONIC
• ANGRYREBEL

Patching your own React and Next.js applications is critical, as is ensuring that vendor and cloud applications have received appropriate patches. Read Checkmarx Zero’s analysis for details.

Checkmarx support

React2Shell is detected by Checkmarx SCA, so your regular SCA scans should report this impact. You can also use your Global Inventory & Risks view to search for react and next to find out if you’re using those components. Consult with your support team for assistance.

Shai-Hulud 3.0 is a stunted worm, and we don’t even get Water of Life

(Too much Dune nerdery? No? Fantastic.)

Despite a few researchers sounding alarms over a “Shai-Hulud 3.0”, the actual vulnerability turned out to be kind of a dud. This looks a lot to me like someone experimenting with the tactics of Shai-Hulud, but failing and producing a stunted worm incapable of causing widespread damage.

The infected package is not in widespread use, so it’s unlikely you’re affected. But the following IOCs may be of use:

"ioc": [
            "4d6b9efc22ec229be58b90c7991c02dd",
            "6914d930998108adfc93b7fe1aa3e64e",
            "github/workflows/discussion.yaml",
            "github/workflows/formatter_123456789.yml"
        ],

Checkmarx Support

Checkmarx SCA will detect this package (as well as the packages known to be impacted by prior Shai-Hulud variants) for customers with the MPP add-on (included with Checkmarx One Professional and Enterprise bundles).

Advanced orgs who have purchased the Malicious Package Identification product (not included with Checkmarx One) can use it to query up-to-date IOCs and get further information about the risk.

MongoBleed: data leaking from MongoDB servers

Attackers who can manage to control zlib-compressed wire-protocol messages sent to a MongoDB server, either directly over the network or by tampering with application inputs, can cause MongoDB to leak contents of the host’s heap memory. A patient attacker can use this to recover memory fragments that contain important secrets, such as encryption keys, authentication tokens, and so on.

While most organizations’ environmental controls (such as placing strict limits on network access to MongoDB instances) will significantly reduce the likelihood of exploitation, the impact is high enough to take this seriously. Especially because it has been disclosed to the CISA KEV (Known Exploited Vulnerabilities), which speaks to its reproducibility.

In short:

• Make sure untrusted and public networks don’t have access to port 27017 (or any alternative MongoDB port)
• Examine IaC configurations to determine if your deployments are unsafely exposing MongoDB instances
• Ensure you update to a patched version of MongoDB Server: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30; versions at or above these releases should be safe from this issue
• If you see evidence of exposure or exploitation, rotate any credentials and keys that might be in use on the MongoDB host

Checkmarx Support

Checkmarx Zero’s open source offerings include a free and open source Infrastructure as Code (IaC) scanner: KICS, which can identify ports open to public networks within many types of IaC systems.

AdonisJS can write arbitrary files to its server

If developers consuming the AdonisJS BodyParser use MultipartFile.move() with defaults for options.name and/or options.overwrite, and an attacker finds out, then that attacker can specify an arbitrary relative path and create or overwrite files on the server.

You’re likely affected if:

• you have a vulnerable version of AdonisJS (prior to 10.1.1 or 11.x prereleases before 11.0.0-next.6) in an application
• that application accepts file uploads as MultipartFile using BodyParser
• the application calls Multipart.move(filename, options), and either omits options or provides one without a sanitized options.name. This can lead to writing files that don’t yet exist.
• the options above also accepts default options.overwrite or sets it to True. With all of the above, this results in being able to overwrite any file the application has write access to.

Patch to 10.1.1 to repair.

Mitigations include:

• Identify applications with the vulnerable components; find unsafe uses of MultipartFile.move() and improve them. You should consider this even if you choose to patch, as it provides defense in depth.
• Ensure web applications run with restricted user accounts in sandboxed environments. System-level access restrictions can prevent serious damage in many cases.

Checkmarx Support

Your regular Checkmarx SCA scans should report this risk. You can also use your Global Inventory & Risks view to search for @adonisjs/bodyparser to find out if you’re using that component. Consult with your support team if you need assistance with this.

RustFS hardcoded credential leads to auth bypass in RPC component

The RustFS object storage system maintainers are learning the pain that comes with hardcoded credentials. In this case, though, the credential that’s in their GitHub repository isn’t for some other remote system: it’s for RustFS itself.

Devs included the token "rustfs rpc" in their code, and checked it in to both client and server components. RustFS uses this to enable gRPC communication between client and server, and there’s no mechanism to rotate it in the affected versions.

This means that if an attacker can see the gRPC port of a RustFS client or server, they can establish an authenticated channel that lets them destroy objects, change policies, and reconfigure RustFS clusters. Whoops.

In my experience, this sort of thing is a lot easier to do by accident than people think. As you’re trying to get something to work (remember, this is still pre-1.0!), sometimes you take a shortcut and forget to go back and fix it. And then someone uses it in production, and bad things happen.

You’re impacted by this if you have a RustFS cluster with a version older than 1.0.0-alpha.78. If you do, patch right away.

Mitigation options include blocking access to gRPC ports, though this can degrade service depending on your requirements.

Checkmarx Support

We can help you avoid similar situations in your own code. Your Checkmarx SAST scan is capable of detecting hard-coded credentials, including gRPC tokens. Selecting the appropriate policy and query configuration is important to discovering such tokens; seek help from your support team if you’re not sure how to detect hardcoded credentials.

Customer or not, Checkmarx Zero offers an open-source secrets scanner that can stand alone: check out 2MS (are you interested in Setec Astronomy?) from our tools page.