ES2602-3885d54d - Application State Type Corruption (ASTC) - Persistent Data Type Assumptions in PHP Applications

[cmullaly-mitre]

Submission File: ES2602-3885d54d-new-application-state-type-corruption.txt

ID: ES2602-3885d54d

SUBMISSION DATE: 2026-02-16 14:18:20

NAME: Application State Type Corruption (ASTC) - Persistent Data Type Assumptions in PHP Applications

DESCRIPTION:

This weakness occurs when an application assumes that persisted data
structures will always conform to an expected type (e.g., objects) without
validating the retrieved state. In some cases, the application itself may
unintentionally mutate or convert the stored data into a different type
(e.g., arrays instead of objects) during normal processing. Subsequent code
that accesses properties or methods assumes the original type, leading to
persistent fatal errors across multiple modules. This can result in
authentication failures, system crashes, or other systemic failures.
Variations include any situation where unsafe assumptions about type
integrity are made across execution paths and persistent state mutation is
possible.

[bugmithlegend]

Hi @cmullaly-mitre , dont forget to assign me

[bugmithlegend]

Hi @cmullaly-mitre

I have found ASTC vulnerability in Axway SecureTransport MFT Software, I have reported it to them and they have acknowledged the bug but as DOS, I have reported it across tons of web applications also such as IBM, F-Secure, Dell, and others that have implmeneted the same software, however, I had to say its DOS so it becomes understandable, but I hate it being misunderstood as diff bug, can we speed up the process ? I also want to make a writeup for it, you can see some triaged bugs here:

[cmullaly-mitre]

Hi @bugmithlegend, this submission is in our queue and the initial review should begin in the next week or so. We appreciate the additional information about having to classify this as a DOS and will consider any differences in our review.

[bugmithlegend]

Hi @cmullaly-mitre

I would like to add a clarification to further support this as a distinct, generalizable weakness class based on my extended research

Generalizability

This pattern is not language-specific. Although initially observed in PHP, similar behavior has been confirmed across:

• Multiple languages (including Java). For example, in Axway SecureTransport, the issue did not stem from the language itself (as it doesn't allow changing data types), but from application-level handling (e.g., encoding/decoding inconsistencies), where input was not transformed as expected and was instead treated as a different data type, leading to the same class of failure
• Different frameworks and technology stacks
• Both web applications and enterprise softwares

The root cause is architectural, not related to dynamic typing. The corruption originates from:

• Internal processing inconsistencies
• Encoding/decoding mismatches (e.g., authentication flows)
• Storage/retrieval transformations
• Application logic mutating persisted state (a key distinguishing characteristic of this weakness)

Cross-Product Presence

This pattern has been identified across multiple real-world products, indicating it is:

• Systematic and repeatable
• Present in shared design patterns
• Likely widespread across additional codebases

Impact Scope

This issue is often misclassified as DoS. However, it more accurately represents persistent application state corruption or critical functionality disruption (e.g., complete authentication failure where no users can log in)

Depending on context and execution flow, impacts include:

• Authentication and security control bypass (MFA, lockout, rate limiting). In one observed case, malformed input led to authentication bypass and privilege escalation due to corrupted state propagation
• Persistent state desynchronization
• Cross-module failure propagation
• Application-wide instability or collapse
• Potential account takeover scenarios

(Additional impact scenarios are detailed in the submitted research paper in the mega link)

Key Distinction

The defining property is:

The application mutates and persists structurally invalid state, and later execution paths assume integrity without validation

This combination of self-mutation + persistence + cross-module assumptions is not covered by existing CWE entries

---

I’m happy to provide additional cross-stack examples if helpful. As an update, IBM has resolved many reports of this bug in the software, and these cases are pending disclosure:

Thank you for your consideration!

[bugmithlegend]

Hi @cmullaly-mitre,

As part of my testing for ASTC, I crafted an “ultimate input” payload containing every possible character that could trigger malformed input or state corruption:

!"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[]^_`abcdefghijklmnopqrstuvwxyz{|}~ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡

The effectiveness of this payload depends on context, such as:

• Input field length restrictions
• Allowed character sets
• Application-specific filtering

By analyzing how the application handles each character, I can identify which inputs violate structural assumptions and reliably trigger ASTC

This approach allows systematic exploration across different fields, modules, and applications, helping confirm the generalizability and reproducibility of ASTC across diverse web apps and softwares

[bugmithlegend]

Hi @cmullaly-mitre

it has been 2 weeks, any updates?