During an external penetration test I identified a critical vulnerability that grants unauthenticated users full visibility of the application side configuration and a direct path to server side code execution.
Introduction
The target site operates on TYPO3 CMS version 6.2.31, a release line that addresses some patches, including the security bulletin referenced as typo3 psa 2020 001. Because the instance still exposes the auxiliary validateHash controller, any visitor can request a Hash based Message Authentication Code for an arbitrary value. TYPO3 relies on that to protect form metadata sent from client to server, once an attacker can mint valid HMACs, every integrity barrier collapses. The following sections reproduce the proof of concept chronology performed during the audit.
Discovery methodology
The reconnaissance phase began with automated fingerprinting through typo3scan. Command line output pinpointed the backend login endpoint and disclosed that the host core is fixed at version 6.2.31:
Given the age of that branch, the I checked public advisories and confirmed that validateHash remains vulnerable. No public exploit code was available, so the corresponding patch was inspected to understand the vulnerability.
The patch notes revealed that a request of the form /?eID=validateHash&value=< payload >&addition= returns a digest calculated with the global encryptionKey. A live probe against production confirmed oracle behaviour - submitting the value test yielded an immediate SHA 1 HMAC: In the HTTP response, I saw below:
In the HTTP response, I saw below:
At this point, the team I was able to sign any payload I wanted, which was necessary to bypass the integrity check that came next.
EXPLOITATION WORKFLOW
Capturing a legitimate HMAC Protected Request
Traffic interception during a standard newsletter sign up supplied a practical specimen of HMAC guarded parameters. The POST targeted /newsletter/newsletter.html and contained two notable fields: variable_pi1[__referrer][@request] and variable_pi1[__trustedProperties]. The latter embedded a serialized PHP array followed by its HMAC:
Because the digest is validated server side before deserialization, forging a substitute object became possible once I could calculate a “fresh” signature.
Generating a PHP Object Injection payload
Using phpggc, a gadget based on GuzzleHttp\Psr7\FnStream was produced. The object’s destructor executes phpinfo, chosen just for demonstrative purposes:
Signing the payload via the Oracle
The serialized object was URL encoded and submitted to validateHash, returning a valid digest (be10[…]5ebb). The payload and its signature now mirrored the format observed in the intercepted request:
In the HTTP response, we can see:
Replaying the tampered newsletter form
In the final step I replaced the original __trustedProperties value with the signed gadget and replayed the entire multipart POST:
As a result, output of phpinfo function was returned:
TYPO3 processed the forged metadata, executed the destructor inside the request context and issued a 303 See Other. The redirected page displayed the complete output of phpinfo(), validating remote code execution under the web server account.
Post exploitation findings
Inspection of the phpinfo disclosure uncovered:
a) clear text database credentials:
b) e-mail API secret:
c) bcrypt hash securing the TYPO3 Install Tool:
The hash was extracted and passed to hashcat, where it succumbed quickly to dictionary attack, providing administrative backend access:
Additional environment variables revealed several internal IP addresses, effectively mapping the application subnet:
Together, these pieces of evidence showed that confidentiality was broken, integrity was at risk, and paths for moving deeper into the system were revealed, all without needing to be logged in.
Conclusion
The audit shows that retaining TYPO3 6.2.31 in production invites catastrophic compromise. By exploiting a single unauthenticated oracle, I escalated from passive fingerprinting to full configuration disclosure and arbitrary code execution, following a six step chain: version identification, HMAC oracle confirmation, live request capture, gadget construction, payload signing and request replay.
