rootdirective-sec/cve-2026-42647-lab# Docker-basiertes Labor zur Reproduktion von CVE-2026-42647, einer unauthentifizierten zeitbasierten Blind-SQL-Injection im JoomSport-WordPress-Plugin über den Parameter `sortf`. Enthält verwundbare und gepatchte Ziele zum Vergleich.
sortfDieses Repository enthält ein lokales Docker-Labor zur Reproduktion und Validierung von CVE-2026-42647, einer unauthentifizierten SQL-Injection-Schwachstelle, die das WordPress-Plugin JoomSport - for Sports: Team & League, Football, Hockey & more betrifft.
Das verwundbare Verhalten tritt in der Sortierfunktion der Spielerliste auf. Ein öffentlicher Besucher kann den Abfrageparameter sortf steuern, der zur Erstellung einer SQL-ORDER BY-Klausel verwendet wird. In verwundbaren Versionen wird der Wert als Text bereinigt und in Backticks gesetzt, aber nicht gegen eine strenge Allowlist validiert, bevor er an die SQL-Abfrage angehängt wird.
Dieses Labor vergleicht zwei JoomSport-Versionen:
| Service | JoomSport-Version | Zweck | URL |
|---|---|---|---|
vuln | 5.7.6 | Verwundbares Vergleichsziel | http://localhost:8081 |
patched | 5.7.8 | Gepatchtes Vergleichsziel | http://localhost:8082 |
Die öffentlichen Advisories identifizieren Versionen vor 5.7.8 als betroffen und 5.7.8 als die behobene Version. Dieses Labor verwendet 5.7.6 als verwundbares Ziel, da zum Zeitpunkt der Erstellung dieses Labors kein 5.7.7-Quellcode-Tag in der SVN-Tag-Liste des WordPress.org-Plugins verfügbar war.
Die demonstrierte Schwachstellenkette ist:```text Unauthenticated visitor → JoomSport season player list route → attacker-controlled sortf parameter → unsafe dynamic ORDER BY construction → SQL expression execution → measurable database delay in vulnerable version → patched version rejects the injected sort field and falls back to a safe allowlisted field
This lab validates the vulnerability as a time-based blind SQL injection. It does not perform database dumping, credential extraction, data modification, or destructive SQL operations.
This lab is designed for controlled local research, source-level understanding, and portfolio demonstration only.
## Verified Facts
| Claim | Evidence | How to verify in this lab |
| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| JoomSport before 5.7.8 is reported vulnerable to unauthenticated SQL injection. | Public advisories identify JoomSport `< 5.7.8` / `<= 5.7.7` as affected. | Review the References section and compare the vulnerable/patched services. |
| JoomSport 5.7.8 is the fixed version. | Public advisories and source comparison show that 5.7.8 validates the `sortf` value before building the ordering expression. | Inspect `class-jsport-playerlist.php` in both versions. |
| The affected parameter is `sortf`. | The vulnerable player list code reads `classJsportRequest::get('sortf')`. | Run the PoC and observe the injected `sortf` request. |
| The vulnerable code builds a dynamic SQL ordering value from user input. | In the vulnerable version, `sortf` is used to build `$options['ordering']`. | Inspect `sportleague/classes/objects/class-jsport-playerlist.php`. |
| The SQL sink is an `ORDER BY` clause. | The generated `$ordering` value is later appended into an SQL query with `ORDER BY`. | Inspect `sportleague/base/wordpress/classes/class-jsport-getplayers.php`. |
| The patch uses an allowlist-style fix. | The patched version introduces allowed static columns and expected dynamic field patterns before using the sort field. | Compare JoomSport 5.7.6 and 5.7.8 source. |
| The lab demonstrates time-based blind SQL injection. | The vulnerable target delays when an injected `SLEEP()` expression is used; the patched target does not. | Run `python3 poc/poc.py http://localhost:8081 http://localhost:8082`. |
## Assumptions and Unknowns
This lab uses JoomSport 5.7.6 as the vulnerable comparison target because the public fixed version is 5.7.8 and a 5.7.7 source tag was not available in the WordPress.org plugin SVN tag listing when the lab was prepared.
The lab does not claim that 5.7.6 is the only vulnerable version. It is used as a reproducible vulnerable baseline for comparing vulnerable behavior against the patched 5.7.8 behavior.
The lab focuses on the `sortf` parameter in the player list sorting flow.
The demonstrated impact is time-based blind SQL injection. The lab does not demonstrate:
* direct database dumping,
* credential extraction,
* authentication bypass,
* privilege escalation,
* arbitrary data modification,
* remote code execution,
* persistence,
* external callbacks,
* or attacks against non-lab systems.
Error-based or boolean-based behavior may be possible depending on database behavior, application configuration, and response differences, but this lab does not rely on those techniques. The primary proof is timing-based.
## Root Cause Summary
The root cause is unsafe construction of a dynamic SQL `ORDER BY` clause from the `sortf` request parameter.
The vulnerable code path starts in:```text
sportleague/classes/objects/class-jsport-playerlist.php
In der Ladelogik der Spielerliste liest JoomSport den Request-Parameter:```text sortf
und verwendet es, um Folgendes zu konstruieren:```text
$options['ordering']
Das relevante verwundbare Quellcode-Muster ist:```php
if (classJsportRequest::get('sortf')) {
$typeAD = in_array(classJsportRequest::get('sortd'), array("ASC","DESC")) ? classJsportRequest::get('sortd') : "ASC";
$options['ordering'] = str_replace(" ","",sanitize_text_field("".classJsportRequest::get('sortf')."")).' '.$typeAD;
}
Das Problem liegt nicht primär am Parameter `sortd`. Der Wert von `sortd` ist beschränkt auf:```text
ASC
DESC
Das Problem ist der Parameter sortf, da er die Position der SQL-Identifikator-/Ausdrucksbezeichnung steuert, die für die Sortierung verwendet wird.
Der gefährliche Ausdruck ist:```php
"".classJsportRequest::get('sortf').""
Der Code platziert angreiferkontrollierte Eingaben in einen MySQL-Identifikatorkontext und reicht sie dann als SQL-Sortierfragment weiter.
Der Code wendet Folgendes an:```php
sanitize_text_field()
aber sanitize_text_field() ist keine SQL-Bezeichner-Validierung. Es ist dafür gedacht, Text zu bereinigen, nicht um sicher SQL-Syntax zu konstruieren.
Der anfällige Code umschließt das vom Benutzer kontrollierte Sortierfeld außerdem in Backticks. Backticks sind jedoch keine Sicherheitsgrenze, wenn der Angreifer den Inhalt des Bezeichners beeinflussen kann. Wenn ein Angreifer einen Backtick in den Wert injizieren kann, kann er aus dem beabsichtigten Bezeichnerkontext ausbrechen.