Someone filed a CVE against a homework project and now it is clogging your scan queue
CVE-2026-13557 is a stored cross-site scripting (XSS) flaw in the itsourcecode Online Hotel Management System 1.0, a free PHP source-code download distributed on itsourcecode.com for students and hobbyists. The vulnerable endpoint is /admin/mod_room/controller.php?action=add, where the Name parameter is reflected without sanitization, allowing an attacker to inject arbitrary JavaScript. The affected version is 1.0 — and there is no 1.1, no vendor patch cadence, and no commercial support. The project is designed to run on XAMPP or WAMP on a developer laptop. It is one of at least six nearly identical XSS/SQLi CVEs filed against different endpoints of the same codebase in the same week (CVE-2026-13552 through CVE-2026-13557).
The vendor CVSS of 4.3 MEDIUM is technically accurate for the XSS mechanics — network-reachable, low complexity, user interaction required, integrity-only impact. But it is *wildly misleading in practice* because it tells you nothing about the deployment population. This software has zero presence in enterprise environments. It is a student project hosted on a free-download PHP tutorial site, intended to be run inside C:\xampp\htdocs\. Treating this as a real MEDIUM in your vulnerability management program wastes analyst cycles that should go toward actual threats. The correct enterprise verdict is IGNORE.
4 steps from start to impact.
Locate exposed instance
- Instance of itsourcecode Online Hotel Management System 1.0 is running and reachable
- Software is a free student project with near-zero production deployment
- Designed for XAMPP/WAMP local dev environments — not production-hardened or production-deployed
- No Shodan/Censys/FOFA fingerprints for this application
Access admin panel
/admin/, meaning the attacker needs to reach the admin interface. The CVSS vector claims PR:N (no privileges required), but the endpoint path is explicitly an admin function. In any real deployment, this would require authentication to the admin panel or network adjacency to a completely unsecured local instance.- Network access to the /admin/ path on the target instance
- Either admin credentials or a completely unsecured instance with no auth
- Endpoint is under /admin/ which implies authentication in any sane deployment
- Most instances are localhost-only dev setups behind NAT
Inject XSS payload into Name field
/admin/mod_room/controller.php?action=add with a <script> tag in the Name parameter. The payload is stored in the database. This is trivial — the PoC is literally <script>alert(document.cookie)</script>. No tooling required beyond curl or a browser.- Ability to submit POST requests to the add-room endpoint
- The payload is stored but only fires when another admin views the room listing
- Single-user student projects rarely have a second admin to target
Victim admin views poisoned page
- A second administrator must browse the room listing page
- The victim's browser must execute inline JavaScript (no CSP)
- Student projects typically have a single user — the developer themselves
- Impact ceiling is session theft within a toy PHP app with no real data
- No lateral movement, no host compromise, no domain impact
- WAF rules for the specific endpoint — technically a WAF would block the XSS, but deploying WAF rules for a student project that should not exist on your network is a misallocation of engineering effort.
- Vendor patching — there is no vendor, no patch, and no update mechanism. You cannot patch this; you can only remove it.
- Input validation consulting with the developer — itsourcecode.com is a free tutorial site, not a software vendor. There is no one to report to and no expectation of a fix.
The supporting signals.
| In-the-Wild Exploitation | None. No evidence of exploitation in the wild. Not listed on CISA KEV. No threat intel reports reference this CVE. No campaigns target this software. |
|---|---|
| Proof-of-Concept | Publicly available — the disclosure itself *is* the PoC (inject <script>alert(document.cookie)</script> into the Name field). Researcher JunyanYip documented similar XSS flaws across this codebase on GitHub. No weaponized exploit exists because there is nothing worth weaponizing. |
| EPSS Score | 0.0047 (0.47%) — 39th percentile. Bottom half of all CVEs. FIRST's model correctly identifies near-zero exploitation probability. |
| KEV Status | Not listed. No CISA KEV entry. No federal mandate to patch. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — Network attack vector, low complexity, no privileges, requires user interaction, unchanged scope, low integrity impact only. No confidentiality or availability impact. The PR:N is debatable since the endpoint is under /admin/. |
| Affected Versions | itsourcecode Online Hotel Management System 1.0 (the only version). This is a static free download, not a maintained product with version releases. |
| Fixed Version | None. No vendor patch exists. No patch cadence. The project has no maintainer, no issue tracker, no update mechanism. |
| Scanning / Exposure | Zero meaningful exposure. No Shodan, Censys, or FOFA fingerprints for this application. It is a student project designed for localhost on XAMPP/WAMP stacks. Enterprise scanners may flag it if a developer left it running, but this is a hygiene finding, not a threat. |
| Disclosure Date | 2026-06-29. Disclosed alongside five other CVEs (13552–13557) filed against the same codebase by the same or similar researchers. |
| Software Context | Free student project from itsourcecode.com — a website that distributes tutorial source code for academic projects. Not commercial software. Not enterprise-grade. Not deployed at scale anywhere. |
Sources.
- OpenCVE — CVE-2026-13557 Detail
- CyberStrike — CVE-2026-13557
- itsourcecode — Online Hotel Management System Source Code
- GitHub — JunyanYip XSS PoC for itsourcecode hotel system
- OpenCVE — All Online Hotel Management System CVEs
- GHSA-m47q-73r3-3mm8 — Prior SQLi in same codebase
- SentinelOne Vuln DB — CVE-2026-13556 (sibling XSS)
Why this verdict
- Baseline vendor score is 4.3 MEDIUM — technically correct for the stored XSS mechanics (network, low complexity, user interaction, integrity-only). Starting from this baseline.
- Zero enterprise deployment footprint (-3.0): This is a free PHP student project from a tutorial download site. It runs on XAMPP. No enterprise, government, or production environment uses this software. The entire premise of vulnerability prioritization — that you have hosts to patch — does not apply. Your fleet of 10,000 hosts has zero instances of this.
- No high-value role overlap (-0.5): This software does not occupy any position in the high-value-role catalog. It is not an identity provider, hypervisor, CI/CD system, backup tool, database engine, security agent, or network edge appliance. It is a PHP toy app. The blast radius is one browser tab in a localhost XAMPP session.
- Role multiplier: The *only* plausible deployment role is (a) low-value: a developer sandbox or student laptop. There is no (b) typical role and no (c) high-value role. The installed base that occupies *any* enterprise role is effectively 0%. The deployment-role blast-radius floor does not activate because no high-value role exists for this component.
- No patch available, but irrelevant: There is no vendor fix, but this does not increase severity because the correct action is to remove the software entirely, not patch it. If you find this on your network, it is an unauthorized/shadow-IT student project.
- CVE spam pattern (-0.3 context penalty): This is one of six nearly identical XSS/SQLi CVEs filed against the same toy codebase in one week. This is a known pattern of researchers padding CVE counts with findings against unmaintained free PHP projects. It wastes defender attention.
Why not higher?
There is no scenario where this CVE warrants LOW or above for an enterprise security team. The software has zero production deployment, zero enterprise install base, zero attacker interest (EPSS 0.47%, no KEV, no campaigns), and the maximum impact is cookie theft within a toy PHP app running on a student's XAMPP. No high-value role exists. The deployment-role blast-radius floor never activates.
Why not lower?
IGNORE is already the lowest possible verdict. A score of 1.5 (rather than 0.0) acknowledges that the XSS technically works as described and a PoC exists, so if somehow an instance were discovered on your network, the finding is real — it is just irrelevant to enterprise risk management.
Crowdsourced verification payload.
Run this on any Linux/macOS auditor workstation or directly on suspected hosts. It checks whether the itsourcecode Online Hotel Management System files exist on the local filesystem (common XAMPP paths) or whether a given URL responds with the application's fingerprint. Usage: bash check_cve_2026_13557.sh [optional-url]. No special privileges needed for the URL check; filesystem check may need read access to web roots.
#!/usr/bin/env bash
# check_cve_2026_13557.sh — Detect itsourcecode Online Hotel Management System 1.0
# CVE-2026-13557: Stored XSS in /admin/mod_room/controller.php
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=VULNERABLE, 1=PATCHED/NOT_FOUND, 2=UNKNOWN
set -euo pipefail
TARGET_URL="${1:-}"
FOUND=0
# --- Filesystem check (common XAMPP/WAMP/Linux paths) ---
WEB_ROOTS=(
"/opt/lampp/htdocs"
"/var/www/html"
"/var/www"
"/usr/share/nginx/html"
)
VULN_FILE="admin/mod_room/controller.php"
for root in "${WEB_ROOTS[@]}"; do
if [ -f "${root}/${VULN_FILE}" ]; then
echo "[!] Found vulnerable file: ${root}/${VULN_FILE}"
# Check if any output encoding is present (rudimentary)
if grep -qP 'htmlspecialchars|htmlentities|strip_tags|esc_attr' "${root}/${VULN_FILE}" 2>/dev/null; then
echo "[i] Output encoding function detected — may be patched."
else
echo "[!] No output encoding found — VULNERABLE"
FOUND=1
fi
fi
done
# --- URL fingerprint check ---
if [ -n "${TARGET_URL}" ]; then
PROBE_URL="${TARGET_URL}/admin/mod_room/controller.php?action=add"
HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "${PROBE_URL}" 2>/dev/null || echo "000")
if [ "${HTTP_CODE}" = "200" ] || [ "${HTTP_CODE}" = "302" ]; then
echo "[!] Admin room endpoint responded (HTTP ${HTTP_CODE}) at ${PROBE_URL}"
FOUND=1
elif [ "${HTTP_CODE}" = "000" ]; then
echo "[?] Could not reach ${PROBE_URL}"
else
echo "[i] Endpoint returned HTTP ${HTTP_CODE} — likely not present or access-controlled."
fi
fi
# --- Verdict ---
if [ "${FOUND}" -eq 1 ]; then
echo "VULNERABLE"
exit 0
elif [ "${FOUND}" -eq 0 ] && { [ ${#WEB_ROOTS[@]} -gt 0 ] || [ -n "${TARGET_URL}" ]; }; then
echo "PATCHED"
exit 1
else
echo "UNKNOWN"
exit 2
fi