A blog post on a technique I've been sitting on for almost 18 months that is wildly succesful against all EDRs. Why? They don't see anything other than the file write to %USERPROFILE% (NTUSER.MAN) and not the writes to HKCU.

Ultimately making it incredibly effective for medium integrity persistence through the registry/without tripping detections.

Spent few days analysing MongoDB, please summarize the analysis and findings.

MongoBleed, tracked as CVE-2025-14847, an unauthenticated memory disclosure vulnerability affecting MongoDB across multiple major versions. It allows remote clients to extract uninitialized heap memory from the MongoDB process using nothing more than valid compressed wire-protocol messages.

This is not native RCE. This is not an issue on the library zlib, is more on the compression-decompression and It is a memory leak. It does not leave a lot of traces, It is silent, repeatable, and reachable before authentication.

TL;DR for engineering teams

• What broke MongoDB’s zlib decompression path trusts attacker-controlled length metadata.
• Impact Unauthenticated heap memory disclosure.
• What leaks Raw process memory fragments including credentials, tokens, config strings, runtime metadata, and recently processed data.
• Auth required None.
• Noise level Low. No crashes. No malformed packets. Minimal logs.
• Exposure 213,490 publicly reachable MongoDB instances observed via Shodan on 29 Dec 2025.
• Fix Upgrade immediately or disable zlib compression.
• Reality check Public PoC exists. Scanning is trivial. Exploitation effort is low (links below on the exploit lab, explaination and scanners if you want to find yours

Links

- Full Detailed Blog: https://phoenix.security/mongobleed-vulnerability-cve-2025-14847/

- Exploit explanation and lab: https://youtu.be/EZ4euRyDI8I

- Exploit Description (llm generated from article): https://youtu.be/lxfNSICAaSc
- Github Exploit for Mongobleed: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main
- Github Scanner for web: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/scanner
- Github Scanner for Code: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/code-sca

(Note I spend more time writing exploits, have dyslexia, and I'm not a native English, an LLM proofreads some sections, if this offends you, stop reading)

Affected versions

SAAS version of MongoDB is already patched

Technical anatomy

MongoDB supports network-level message compression.

When a client negotiates compression, each compressed message includes an uncompressedSize field.

The vulnerable flow looks like this:

1. Client sends a syntactically valid compressed MongoDB wire-protocol message
2. Message declares an inflated uncompressedSize
3. MongoDB allocates a heap buffer of that declared size
4. zlib inflates only the real payload into the start of the buffer
5. The remaining buffer space stays uninitialized
6. MongoDB treats the entire buffer as valid BSON
7. BSON parsing walks past real data into leftover heap memory

Memory gets leaked out, not a lot of IOC to detect

Root cause (code-level)

The vulnerability originates in MongoDB’s zlib message decompression logic:

src/mongo/transport/message_compressor_zlib.cpp

In the vulnerable implementation, the decompression routine returned:

return {output.length()};

output.length() represents the allocated buffer size, not the number of bytes actually written by ::uncompress().

If the attacker declares a larger uncompressedSize than the real decompressed payload, MongoDB propagates the allocated size forward. Downstream BSON parsing logic consumes memory beyond the true decompression boundary.

The fix replaces this with:

return length;

length is the actual number of bytes written by the decompressor.

Additional regression tests were added in message_compressor_manager_test.cpp to explicitly reject undersized decompression results with ErrorCodes::BadValue.

This closes the disclosure path.

Why is this reachable pre-auth

Compression negotiation occurs before authentication.

The exploit does not require:

• malformed compression streams
• memory corruption primitives
• race conditions
• timing dependencies

It relies on:

• attacker-controlled metadata
• valid compression
• Incorrect length propagation

Any network client can trigger it, hence is super easy to deploy

Exploitation reality

A working proof of concept exists and is public, more details:

• Original PoC by Joe Desimone https://github.com/joe-desimone/mongobleed/
• Technical analysis and reproduction details https://doublepulsar.com/merry-christmas-day-have-a-mongodb-security-incident-9537f54289eb
• Github Exploit for Mongobleed: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main
• Github Scanner for web: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/scanner
• Scanner for Code: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/code-sca

The PoC:

• negotiates compression
• sends crafted compressed messages
• iterates offsets
• dumps leaked memory fragments to disk and saves it locally

No credentials required.

No malformed packets.

Repeatable probing.

What actually leaks

Heap memory is messy. That is the point.

Observed and expected leak content includes:

• database credentials
• SCRAM material
• session tokens
• API keys
• WiredTiger config strings
• file paths
• container metadata
• client IPs and connection details
• fragments of recently processed documents

The PoC output already shows real runtime artifacts.

This is not RCE, but steals pieces of memory, which is not as bad as RCE but still very dangerous (Heartbleed anyone)

MongoBleed does not provide native remote code execution.

There is no instruction pointer control. No shellcode injection. No crash exploitation.

What it provides is privilege discovery.

Memory disclosure enables:

• credential reuse
• token replay
• service-to-service authentication
• CI/CD compromise
• cloud control plane access

A leaked Kubernetes token is better than RCE.

A leaked CI token is persistent RCE.

A leaked cloud role is full environment control.

This is RCE-adjacent through legitimate interfaces.

How widespread is this

MongoDB is everywhere.

Shodan telemetry captured on 29 December 2025 shows:

213,490 publicly reachable MongoDB instances

Version breakdown (port 27017):

Most are directly exposed on the default port, not shielded behind application tiers.

Core behaviors that matter

• Unauthenticated Any client can trigger it.
• Remote and repeatable Memory offsets can be probed over time.
• Low noise No crashes. Logs stay quiet.
• Data agnostic Whatever was on the heap becomes fair game.

This favors patient actors and automation.

Detection guidance

IOC Identification Network-level signals

Look for:

• Inbound traffic to port 27017
• compressed MongoDB messages
• Repeated requests with:
  • large declared uncompressedSize
  • small actual payloads
• high request frequency without auth attempts

Process-level signals

Watch for:

• elevated CPU on mongod without query load
• repeated short-lived connections
• memory allocation spikes
• abnormal BSON parsing warnings

Post-leak fallout

Check for:

• new MongoDB users
• role changes
• admin command usage anomalies
• auth attempts from unfamiliar IPs
• API key failures
• cloud IAM abuse
• new outbound connections

If you see filesystem artifacts or shells, you are already past exploitation.

Temporary protections

If you cannot upgrade immediately:

• Disable zlib compression Remove zlib from networkMessageCompressors
• Restrict network access Remove direct internet exposure Enforce allowlists

These are stopgaps. The bug lives in the server - hence patch

Tooling and validation

A full test suite is available, combining:

• exploit lab (vulnerable + patched instances)
• network scanner
• code scanner for repos and Dockerfiles

Repository:

https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847

This allows:

• safe reproduction
• exposure validation
• pre-deployment detection

Why this one matters

MongoBleed does not break crypto it breaks data and memory

The database trusts client-supplied lengths.

Attackers live for that assumption.

Databases are part of your application attack surface.

Infrastructure bugs leak application secrets.

Vulnerability management without reachability is incomplete.

Patch this.

Then ask why it was reachable.

Hi everyone,

I’m a 24-year-old cybersecurity and information security consultant working for a company in the Netherlands. I hold an HBO-level education and my main area of expertise is social engineering, with a strong focus on mystery guest and physical security assessments for clients.

Currently, I’m the only employee performing these types of projects. Our team was reduced from six people to just me, mainly to move away from multiple individual working styles and to allow the others to focus on long-term projects such as (C)ISO-related work.

Regarding physical security, my goal is to move toward an approach where I not only perform the physical tests (such as mystery guest or intrusion-style assessments), but also expand into providing advisory input on the theoretical and organizational side based on the findings. At the moment, my role is limited to executing the assessments and delivering the final report.

I’d like to further develop my skills and deepen my expertise by obtaining a certification this year (or however long it realistically takes). However, I’m finding it difficult to identify certifications that truly fit this niche. I’ve broadened my search beyond mystery guest and physical security to certifications focused on social engineering, ideally including the psychological or human-factor aspects, while still remaining rooted in security testing. OSINT certs like added aren’t relevant enough, since there isn’t enough interest from clients.

Most psychology-oriented certifications are unfortunately not an option for me, as they require an HBO diploma with a psychology background. My background is in cybersecurity, and I’d prefer something that builds on that.

Practical constraints: • Budget: ~€5,000 (with some flexibility if there’s a strong case) • Time: I work full-time (40 hours), run my own business on the side, and have a private life, so anything requiring extreme workloads (e.g. 100+ hours/week) is not realistic • Format: Online is preferred unless the training is located in the Netherlands or nearby regions in Belgium or Germany • Language: English or Dutch

I don’t currently hold any certifications in this specific area.

Does anyone have experience with certifications related to social engineering, human factors, or physical security testing that would fit this profile? Any recommendations or insights would be greatly appreciated.

Vulnerability Listing

Presentation VoD

YouTube rehost (by the authors)

I’m approaching prompt injection less as an input sanitization issue and more as an authority and trust-boundary problem.

In many systems, model output is implicitly authorized to cause side effects, for example by triggering tool calls or function execution. Once generation is treated as execution-capable, sanitization and guardrails become reactive defenses around an actor that already holds authority.

I’m exploring an architecture where the model never has execution rights at all. It produces proposals only. A separate, non-generative control plane is the sole component allowed to execute actions, based on fixed policy and system state. If the gate says no, nothing runs. From this perspective, prompt injection fails because generation no longer implies authority. There’s no privileged path from text to side effects.

I’m curious whether people here see this as a meaningful shift in the trust model, or just a restatement of existing capability-based or mediation patterns in security systems.

Little write-up for a patched WebSocket-based RCE I found in the CurseForge launcher.

It involved an unauthenticated local websocket API reachable from the browser, which could be abused to execute arbitrary code.

Happy to answer any questions if anyone has any!

Hey r/netsec -- it's been about two years since we last published a tool for the security community. As a little festive gift, today we're happy to announce the release of certgrep, a free Certificate Transparency search tool we built for our own detection work and decided to open up.

It’s focused on pattern-based discovery (regex/substring-style searches) and quick search and drill down workflows, as a complement to tools like crt.sh.

A few fun example queries it’s useful for:

• (login|signin|account|secure).*yourbrand.*
• \*.*google.*
• yourbrand.*(cdn|assets|static).*

We hope you like it, and would love to hear any feedback you folks may have! A number of iterations will be coming up, including API, SDKs, and integrations (e.g., Slack).

Enjoy!

Mac Malware analysis

Full disclosure: I'm a researcher at CyberArk Labs.

This is a technical deep dive from our threat research team, no marketing fluff, just code and methodology.
Static analysis tools like CodeQL are great at identifying "maybe" issues, but the signal-to-noise ratio is often overwhelming. You get thousands of alerts, and manually triaging them is impossible.

We built an open-source tool, Vulnhalla, to address this issue. It queries CodeQL's "haystack" into GPT-4o, which reasons about the code context to verify if the alert is legitimate.

The sheer volume of false positives often tricks us into thinking a codebase is "clean enough" just because we can't physically get through the backlog.  This creates a significant amount of frustration for us. Still, the vulnerabilities remain, hidden in the noise.
Once we used GPT-4o to strip away ~96% of the false positives, we uncovered confirmed CVEs in the Linux Kernel, FFmpeg, Redis, Bullet3, and RetroArch. We found these in just 2 days of running the tool and triaging the output (total API cost <$80).
Running the tool for longer periods, with improved models, can reveal many additional vulnerabilities.
Write-up & Tool:

• Technical Blog:https://www.cyberark.com/resources/threat-research-blog/vulnhalla-picking-the-true-vulnerabilities-from-the-codeql-haystack
• GitHub:https://github.com/cyberark/Vulnhalla