# GLPI GHSA-753w-2942-4pxm - unauthenticated SQL injection (planning)

Defensive detection pack for an unauthenticated SQL injection in GLPI’s planning feature.

| Field | Value (confirmed) |
|---|---|
| Identifier | **GHSA-753w-2942-4pxm** (no CVE assigned as of 2026-10-22) |
| Class | Unauthenticated SQL injection (CWE-89) |
| Affected | GLPI **≤ 11.0.8** (11.x), per researcher write-up |
| Fixed | **11.0.9** (released 2026-09-16; release notes list “Unauthenticated SQL injection in planning feature”) |
| Entry point | `front/planning.php` with **both** `genical` and `checkavailability` query parameters |

## Source verification (pack build: 2026-10-22 Europe/London)

| Source | Result |
|---|---|
| https://github.com/glpi-project/glpi/security/advisories (GHSA-753w-2942-4pxm) | **Advisory page not published yet** (API/HTML 404). Researcher notes “Advisory … coming soon”. |
| https://github.com/glpi-project/glpi/releases/tag/11.0.9 | Confirms security release on 2026-09-16 including “Unauthenticated SQL injection in planning feature”. |
| Security researcher write-up (primary for technique) | Documents `genical` skipping `Session::checkRight`, `checkavailability` short-circuiting token validation, and raw concatenation into `QueryExpression`. Affected ≤11.0.8; fixed 11.0.9. GLPI 10 not exploitable via this injection path. |

**Unverified / discrepancies:** Official GitHub advisory body and CVE id are not available yet. Treat version ranges as researcher + release-notes confirmed. Do not invent IOCs beyond the disclosed parameter combination.

## Technique (for defenders)

Sending `genical` and `checkavailability` together to `front/planning.php` reaches `Planning::checkAvailability()` without the normal rights/CSRF/token checks. Date parameters were concatenated into SQL on affected builds. This pack **does not** include payloads and **must not** be used for active SQLi testing.

## Files

| File | Purpose |
|---|---|
| `check_glpi.sh` / `check_glpi.ps1` | Read-only local version checkers (`version/` file, `inc/define.php`, optional `php bin/console glpi:system:status`) |
| `scan_logs.sh` | Read-only Apache/Nginx/IIS access-log scanner for the parameter combination |
| `db_review_queries.sql` | Manual read-only SQL notes for recently created admins / API tokens |
| `kql/glpi_planning_param_combo.kql` | Sentinel-style hunts (CommonSecurityLog, W3CIISLog, Syslog, AppServiceHTTPLogs) |
| `sigma/web_glpi_planning_genical_checkavailability.yml` | Sigma (webserver category) |
| `tests/` | shellcheck, mocked checker verdicts, pwsh parse, sigma check |

Remote version probing is **not** implemented: GLPI does not expose a reliably passive public version endpoint without authentication. Use local filesystem/CLI checks.

## Usage

```bash
# Version check (Linux)
bash check_glpi.sh /var/www/glpi
GLPI_DIR=/opt/glpi GLPI_USE_CLI=1 bash check_glpi.sh

# Version check (Windows PowerShell)
pwsh -File check_glpi.ps1 -GlpiDir 'C:\inetpub\wwwroot\glpi'

# Access-log hunt (read-only)
bash scan_logs.sh /var/log/nginx /var/log/apache2 /var/log/httpd
bash scan_logs.sh /path/to/u_ex241020.log

# DB review (manual, SELECT-only account)
mysql -u readonly -p glpi < db_review_queries.sql
```

## Verdicts and exit codes (checkers)

| Verdict | Meaning | Exit |
|---|---|---|
| PATCHED | Not installed, or version ≥ 11.0.9 (or ≥ 12) | 0 |
| LIKELY VULNERABLE | 11.x and &lt; 11.0.9 | 1 |
| UNKNOWN | Version unreadable, or pre-11 branch | 2 |
| ERROR | I/O or unexpected failure | 3 |

`scan_logs.sh`: exit 0 = no hits, 1 = hits, 3 = usage/error.

## Proactive steps

1. Upgrade all GLPI 11.x instances to **≥ 11.0.9** (or current supported release).
2. Ensure planning/UI endpoints are not exposed to untrusted networks; prefer VPN / SSO / IP allow lists.
3. Deploy the Sigma/KQL hunts on reverse-proxy, WAF, IIS, and webserver logs.
4. Restrict DB accounts used by the app; avoid overly privileged MySQL users.

## Reactive steps

1. Run `scan_logs.sh` (and KQL) for `planning.php` with both parameter names; preserve raw logs.
2. If hits exist on an unpatched host, treat as suspected exploitation attempt: isolate, snapshot, rotate credentials/API tokens, review admin users (`db_review_queries.sql`).
3. Patch to ≥ 11.0.9 before returning the host to service.
4. Review application and SQL general logs around hit timestamps for anomalous queries (do not replay attacker input).

## Limits

- Checkers are **read-only** and never send exploit traffic.
- Parameter-name hits are not proof of successful SQLi.
- KQL in this pack is **untested against a live tenant**; validate field names for your connectors.
- GHSA page / CVE were unpublished at build time - re-check the official advisory when it appears.