The Over-Helpful Doorman: Full Account Takeover in 'Known' CMS

In the world of web application security, there is a fine line between 'User Experience' and 'Catastrophic Failure'. The developers of Known, a Fediverse-ready social publishing platform, decided to cross that line, sprint a mile past it, and set up camp in the land of insecure direct object references. The vulnerability, designated CVE-2026-26273, is a textbook example of what happens when code tries to be too helpful.

Usually, the password reset dance is boring but secure: you ask for a link, the server generates a token, emails it to you, and waits. The server trusts the email provider to deliver the secret key to the right person. Known, however, decided to shortcut this process. Instead of treating the reset token as a holy artifact that should only exist in the database and the user's email inbox, the application decided to pre-populate it in the HTML for anyone who asked nicely.

Imagine you lose your house keys. You call a locksmith. A secure locksmith asks for ID. The locksmith in this scenario—Known—just asks, 'Hey, are you the guy who lives at 123 Fake Street?' If you say yes, he hands you a copy of the key he keeps under the mat. This isn't complex memory corruption; it's a fundamental logic failure that results in a trivial, unauthenticated Account Takeover (ATO) of any user on the platform.

The root cause resides in Idno/Pages/Account/Password/Reset.php, specifically within the getContent() method. This function handles the HTTP GET request when a user navigates to the password reset page. In a sane implementation, this page should either ask for the token (if clicked from an email) or tell the user to check their inbox. It should never know what the token is unless the user provides it.

However, the code logic took a fatal detour. When a request arrived with an email parameter (e.g., ?email=victim@target.com), the application instantiated the user object associated with that email. So far, standard procedure. But then, it did the unthinkable: it queried the database for the user's current active password recovery code.

It didn't stop there. Having fetched this secret, the application passed it directly into the template engine. The intention was likely to 'help' legitimate users who might have clicked a malformed link or to pre-fill state for the form submission. The result, however, was that the secret token was rendered into the HTML source code of the page, sitting quietly in a hidden input field, waiting to be scraped.

Let's look at the PHP code responsible for this disaster. This is a reconstruction of the vulnerable logic in getContent() prior to version 1.6.3:

// VULNERABLE CODE (Simplified)
$email = $this->getInput('email');
if ($user = \Idno\Entities\User::getByEmail($email)) {
    // FATAL ERROR: Fetching the secret directly from the DB
    $code = $user->getPasswordRecoveryCode();
    
    // Passing the secret to the template
    $t = \Idno\Core\site()->template();
    $t->__(['code' => $code])->draw('account/password/reset');
}

And inside the template, the betrayal is complete:

<!-- rendered HTML output -->
<form action="/account/password/reset" method="post">
    <input type="hidden" name="code" value="[SECRET_TOKEN_HERE]">
    <input type="password" name="password" placeholder="New Password">
    ...
</form>

The fix, applied in commit 8439a0747471559fb1ea9f074b929d390f27e66a, introduces basic sanity checks. It forces the user to provide the code via the URL first, and then uses hash_equals (a constant-time string comparison function) to validate it against the database. If they don't match, or if the code wasn't provided, the form is never rendered with the token.

// PATCHED CODE
$code = $this->getInput('code');
if (!empty($code) && hash_equals($code, $user->getPasswordRecoveryCode())) {
   // Only render if the user ALREADY knows the code
   $t->__(['code' => $code])->draw('account/password/reset');
}

Exploiting this is trivially easy. It requires no special tooling—just a web browser and the 'View Source' button. Here is the kill chain for taking over the administrator account.

Step 1: The Trigger First, we need the server to generate a token. We send a standard POST request to the 'Forgot Password' endpoint. The server dutifully generates a random token, saves it to the database, and emails it to the victim. We don't have access to the victim's email, but thanks to this bug, we don't need it.

Step 2: The Retrieval We navigate to the reset page, appending the victim's email address to the URL: https://target-site.com/account/password/reset/?email=admin@target-site.com. The application sees the email, looks up the admin user, grabs the token we just triggered in Step 1, and serves us the page.

Step 3: The Extraction We right-click and select Inspect Element (or View Source). We search for name="code". There it is: <input type="hidden" name="code" value="29d390f27e66a...">.

Step 4: The Takeover We don't even need to craft a custom POST request. We just type a new password into the form presented on the screen and hit 'Save'. Because the form was pre-filled with the valid token by the server itself, the password change is accepted. We now own the admin account.

This is a CVSS 9.8 for a reason. In a social publishing platform, an Account Takeover is not just about reading DMs. It is about reputation destruction and potential supply chain attacks.

If an attacker compromises an administrator account on a Known instance, they can:

1. Deface the site: Replace all content with malware links or propaganda.
2. inject XSS: Add malicious JavaScript to the site template, attacking every visitor (watering hole attack).
3. Delete Data: Wipe the database, destroying years of content.
4. Federation Attacks: Since Known talks to the Fediverse (ActivityPub), an attacker could broadcast malicious content to connected servers, masquerading as the trusted instance.

This is a 'Game Over' vulnerability. There is no mitigation other than patching. If your instance is exposed to the internet and running < 1.6.3, it is likely already compromised.