Includes all findings, status, endpoints, and evidence URLs (vulnhost-lab-export schema).
26 exploitable
0 pending
12 blocked
Exploitable 26
Panel reachable from runner
Attacker opens a browser (or scanner) and navigates to the site root URL with no login.
Diagnostics · server_connectivity
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Verify the target panel URL responds.
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens a browser (or scanner) and navigates to the site root URL with no login.
2. The VulnHost dashboard HTML loads with HTTP 200 — the application is exposed to the network.
What happened on this run
----------------
The panel homepage loaded without error; the target is reachable from the internet or test network.
Technical observations
----------------
• HTTP status: 200
• URL: https://testi.compla.nl
Security impact
----------------
Exposure increases attack surface if the app is not meant to be public.
Recommended fix
----------------
Restrict access by VPN, firewall, or the lab PIN gate; monitor external reachability.
What we tested
----------------
Check whether default administrator credentials still work.
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens /login.php in the browser.
2. They enter username admin and password admin123 (documented lab defaults) and submit the form.
3. They are redirected to the dashboard; the header shows Logout and the username admin — full admin session without guessing.
What happened on this run
----------------
Login succeeded with factory credentials; no MFA or lockout stopped the attempt.
Technical observations
----------------
• Credentials tried: admin / admin123
Security impact
----------------
Immediate admin compromise for anyone who knows or tries default creds.
Recommended fix
----------------
Force password change on install, disable default accounts, enable MFA, alert on default-login patterns.
What we tested
----------------
Check SQL injection on the login form that bypasses authentication.
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens /login.php.
2. In both username and password fields they submit the payload: ' OR '1'='1
3. The application logs them in without a valid password because the SQL WHERE clause becomes always true.
What happened on this run
----------------
A session was created using only malicious SQL in the login fields.
Technical observations
----------------
• Payload (user & pass): ' OR '1'='1
Security impact
----------------
Unauthenticated login as an arbitrary user, often the first DB row (admin).
Recommended fix
----------------
Use prepared statements only; never concatenate user input into SQL.
What we tested
----------------
Read the secret .env file via path traversal in the file viewer.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in (e.g. admin / admin123).
2. In the browser they open /view.php?file=../../.env (or use the View file UI and change the file parameter to ../../.env).
3. The page renders the contents of .env in the browser, including lines like PANEL_SECRET= and API_KEY=.
What happened on this run
----------------
Secrets from the server filesystem appeared in the HTTP response body.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/view.php?file=../../.env
• Marker: PANEL_SECRET= in body
Security impact
----------------
Theft of API keys, panel secrets, and credentials for further attacks.
Recommended fix
----------------
Map files to an allow-list under storage/; reject ..; use realpath() checks; keep .env outside web-readable paths.
Attacker logs in, then visits /view.php?file=../../config/database.php in the address bar.
Path traversal · read_config
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Leak PHP config that contains hardcoded secrets.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in, then visits /view.php?file=../../config/database.php in the address bar.
2. The response shows PHP source including fallback_password and other secrets.
What happened on this run
----------------
Config source code was displayed in the browser.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/view.php?file=../../config/database.php
Security impact
----------------
Backup passwords and DB settings aid credential stuffing and pivoting.
Recommended fix
----------------
Same as path traversal fixes; never store secrets in web-accessible trees.
Attacker logs in, then opens /view.php?file=....//....//.env in the browser.
Path traversal · traversal_bypass
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Bypass weak ../ filters using encoded traversal.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in, then opens /view.php?file=....//....//.env in the browser.
2. The doubled-dot pattern evades naive filters but still resolves to .env on the server.
3. Sensitive .env lines (e.g. API_KEY=) appear in the page.
What happened on this run
----------------
Filter bypass returned .env content.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/view.php?file=....//....//.env
Security impact
----------------
WAF/filter evasion plus arbitrary file read.
Recommended fix
----------------
Canonicalize paths on the real filesystem; deny if outside allowed base directory.
Attacker logs in and opens /include.php?page=../../.env
LFI · lfi_env
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Local file inclusion via dynamic include.php.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and opens /include.php?page=../../.env
2. The include handler loads ../../.env as the page template and prints secret lines into the HTML.
What happened on this run
----------------
.env content visible in the included page output.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/include.php?page=../../.env
Security impact
----------------
File read and potential RCE via include tricks or log poisoning.
Recommended fix
----------------
Never pass user input to include/require; use a fixed allow-list of template names.
What we tested
----------------
Upload a PHP web shell without type validation.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and opens /upload.php.
2. They choose a file named shell.php containing PHP code and submit the upload form.
3. They browse to /uploads/<filename>.php — if the server executes PHP in uploads/, the shell runs.
What happened on this run
----------------
A .php file was accepted and stored (and may execute depending on server config).
Technical observations
----------------
• Upload HTTP status: 200
• Filename: lab_test_1790602947.php
• Execution: Stored; PHP not executed (common on Apache/nginx)
Security impact
----------------
Persistent remote code execution on the server.
Recommended fix
----------------
Allow-list extensions, scan content, store outside web root, disable PHP in upload directories.
Attacker uploads a file named something.php.jpg containing PHP code.
Upload · double_extension_upload
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Bypass naive extension filters with double extensions (e.g. shell.php.jpg).
How the attacker reproduced this (browser steps)
----------------
1. Attacker uploads a file named something.php.jpg containing PHP code.
2. Weak panels only check the last extension or MIME sniffing — file may be stored and sometimes executed.
What happened on this run
----------------
File stored and/or PHP marker executes when requesting /uploads/<name>.
Technical observations
----------------
• Upload HTTP status: 200
• Filename: shell_VULNHOST_DOUBLEEXT_5ea9667a.php.jpg
• PHP executed: no
Security impact
----------------
Remote code execution if the server maps .php.jpg to PHP.
Recommended fix
----------------
Allow-list safe extensions; inspect content; randomize stored names; disable PHP in upload dirs.
Attacker links to /redirect.php?next=https://evil.example/phish (logout, SSO, or marketing redirect).
Redirect · open_redirect
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Redirect victims to an attacker site using an unvalidated next/url parameter.
How the attacker reproduced this (browser steps)
----------------
1. Attacker links to /redirect.php?next=https://evil.example/phish (logout, SSO, or marketing redirect).
2. Browser follows HTTP 302 Location to the attacker URL — trusted domain in the address bar first.
What happened on this run
----------------
Location header points to the external attacker URL unchanged.
Technical observations
----------------
• HTTP status: 302
• Location: https://evil.vulnhost-lab.example/phish
• Expected: https://evil.vulnhost-lab.example/phish
Security impact
----------------
Phishing, OAuth token theft, malware downloads.
Recommended fix
----------------
Allow only relative paths or fixed host allow-list; never pass raw user URL to Location.
Attacker hosts a page that auto-POSTs email=attacker@evil to /admin.php.
CSRF · csrf_admin_email
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Change admin settings with a cross-site form POST (no CSRF token).
How the attacker reproduced this (browser steps)
----------------
1. Attacker hosts a page that auto-POSTs email=attacker@evil to /admin.php.
2. Victim admin visits while logged in — or in this lab, admin.php may accept anonymous POST.
What happened on this run
----------------
Admin email updated or probe address visible on /admin.php without anti-CSRF controls.
Technical observations
----------------
• POST status: 200
• Probe email: csrf-probe-41616026@evil.test
• GET admin: 200
Security impact
----------------
Account takeover flows, password reset poisoning, social engineering.
Recommended fix
----------------
CSRF tokens on all state-changing POSTs; SameSite=Strict cookies; re-auth for sensitive actions.
Attacker logs in and calls /tools/fetch.php?url=file:///etc/passwd (or file:// paths to .env).
SSRF · ssrf_file_scheme
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Use SSRF to read local files via file:// URLs.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and calls /tools/fetch.php?url=file:///etc/passwd (or file:// paths to .env).
2. Server-side fetch returns file contents in the HTML response.
What happened on this run
----------------
Local file content (e.g. root: from /etc/passwd) appeared in the response.
Technical observations
----------------
• HTTP status: 200
• URL: file:///etc/passwd
Security impact
----------------
Read secrets and system files from the app server.
Recommended fix
----------------
Allow only http(s) to approved hosts; block file:// and private IPs.
Attacker's site sends fetch() to /api/whoami.php with Origin: https://evil.example and cookies.
CORS · cors_permissive_api
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Detect APIs that reflect Origin with credentials allowed.
How the attacker reproduced this (browser steps)
----------------
1. Attacker's site sends fetch() to /api/whoami.php with Origin: https://evil.example and cookies.
2. Response includes Access-Control-Allow-Origin matching evil and Allow-Credentials: true.
What happened on this run
----------------
Permissive CORS headers allow cross-origin authenticated reads.
Technical observations
----------------
• Origin: https://evil.vulnhost-lab.example
• ACAO: https://evil.vulnhost-lab.example
• Credentials: true
Security impact
----------------
Steal JSON session data from victims who visit attacker pages while logged in.
Recommended fix
----------------
Never use * with credentials; strict Origin allow-list; use same-site cookies.
Attacker script sends many POST /login.php attempts with wrong passwords.
Authentication · login_no_rate_limit
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Check whether failed logins are throttled or locked out.
How the attacker reproduced this (browser steps)
----------------
1. Attacker script sends many POST /login.php attempts with wrong passwords.
2. No HTTP 429, captcha, or lockout message appears within the burst.
What happened on this run
----------------
All attempts processed without rate limiting (brute force feasible).
Technical observations
----------------
• Attempts: 8
• Rate limited: no
• Last status: 200
Security impact
----------------
Offline-quality guessing against live accounts.
Recommended fix
----------------
Exponential backoff, CAPTCHA, account lockout, WAF rate limits.
Low-privilege user alice POSTs /profile.php with role=admin.
Access control · mass_assignment_role
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Prevent users from setting privileged fields via profile forms.
How the attacker reproduced this (browser steps)
----------------
1. Low-privilege user alice POSTs /profile.php with role=admin.
2. Database role column updates without server-side allow-list.
What happened on this run
----------------
Dashboard shows alice as admin after mass assignment.
Technical observations
----------------
• User: alice
• POST role: admin
Security impact
----------------
Vertical privilege escalation to administrator.
Recommended fix
----------------
Bind only whitelisted fields; never trust role/is_admin from POST.
Scanner requests /backup.zip, /site.zip, /db.sql.gz, etc.
Disclosure · exposed_backup_zip
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Find downloadable backup archives in the web root.
How the attacker reproduced this (browser steps)
----------------
1. Scanner requests /backup.zip, /site.zip, /db.sql.gz, etc.
2. HTTP 200 returns a zip file (PK signature).
What happened on this run
----------------
backup.zip (or similar) downloadable without auth.
Technical observations
----------------
• HTTP status: 200
Security impact
----------------
Full site + database leak from one URL.
Recommended fix
----------------
Never place backups under public/; use off-site encrypted storage.
What we tested
----------------
Baseline protective headers on HTML pages.
How the attacker reproduced this (browser steps)
----------------
1. Attacker loads / and inspects response headers.
2. X-Frame-Options and Content-Security-Policy are both absent.
What happened on this run
----------------
Neither X-Frame-Options nor CSP is set (clickjacking / XSS impact worse).
Technical observations
----------------
• X-Frame-Options: (missing)
• CSP: (missing)
Security impact
----------------
Easier clickjacking and inline script abuse.
Recommended fix
----------------
Add CSP, X-Frame-Options or frame-ancestors, HSTS, Referrer-Policy.
Attacker logs in as one user, then changes the URL to /files.php?user=2
Access control · idor_files
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
List another tenant's files by changing a user ID parameter.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in as one user, then changes the URL to /files.php?user=2
2. The page lists filenames from tenant 2 (e.g. idor_probe.txt) without verifying the session may access that tenant.
What happened on this run
----------------
Another user's file list appeared in the browser.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/files.php?user=2
Security impact
----------------
Horizontal privilege escalation and data enumeration.
Recommended fix
----------------
Derive tenant/user ID from the session only; ignore client-supplied user= parameters.
Attacker logs in and requests /download.php?file=tenant-2/idor_probe.txt in the browser.
Path traversal · download_traversal
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Download files across tenants via predictable paths.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and requests /download.php?file=tenant-2/idor_probe.txt in the browser.
2. The file body (e.g. idor-ok) downloads or displays — no check that the session owns tenant-2.
What happened on this run
----------------
Cross-tenant file content was returned.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/download.php?file=tenant-2/idor_probe.txt
Security impact
----------------
Confidential file exfiltration by path guessing.
Recommended fix
----------------
Authorize downloads against DB records tied to the current user; never use raw client paths.
Attacker opens /admin.php in a private/incognito window with no session cookie.
Access control · admin_no_auth
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Access admin functions without logging in.
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens /admin.php in a private/incognito window with no session cookie.
2. The full administration UI loads, including user delete forms — no redirect to login.
What happened on this run
----------------
Admin pages rendered anonymously.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/admin.php (no cookie)
Security impact
----------------
Full administrative control without credentials.
Recommended fix
----------------
Require auth + role middleware on every admin route.
Attacker logs in and opens the Ping tool at /tools/ping.php.
Command injection · cmd_injection
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Execute OS commands via the ping tool.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and opens the Ping tool at /tools/ping.php.
2. In the host field they enter: 127.0.0.1; echo VULNHOST_CMDI_OK (Unix) or use & on Windows.
3. Submit — the page shows ping output plus VULNHOST_CMDI_OK, proving shell metacharacters ran a second command.
What happened on this run
----------------
Injected command output appeared in the tool response.
Technical observations
----------------
• HTTP status: 200
• Host parameter: 127.0.0.1; echo VULNHOST_CMDI_OK
Security impact
----------------
Remote code execution as the web server OS user.
Recommended fix
----------------
Do not call shell with user input; validate hostnames with strict allow-list regex.
Attacker logs in and opens /tools/fetch.php?url= with a target URL (e.g. same-site /robots.txt or file:///.env on some runners).
SSRF · ssrf_local
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Force the server to fetch attacker-chosen URLs (SSRF).
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and opens /tools/fetch.php?url= with a target URL (e.g. same-site /robots.txt or file:///.env on some runners).
2. The server fetches that URL server-side and returns the body in the browser — attacker reads internal or local content.
What happened on this run
----------------
Server-side fetch returned the requested resource content to the attacker.
Technical observations
----------------
• HTTP status: 200
• Fetched URL: https://testi.compla.nl/robots.txt
• Note: Python runner uses HTTP SSRF to same-origin robots.txt
Security impact
----------------
Internal network probing, cloud metadata theft, local file read via file://.
Recommended fix
----------------
Block private IPs, metadata IPs, and file://; use an allow-list of outbound hosts.
Attacker crafts a link: /search.php?q=<vulnhost-xss-probe> (or a script tag) and opens it in the browser.
XSS · reflected_xss
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Reflected XSS via search query echoed in HTML.
How the attacker reproduced this (browser steps)
----------------
1. Attacker crafts a link: /search.php?q=<vulnhost-xss-probe> (or a script tag) and opens it in the browser.
2. The search page prints the query unescaped inside HTML (e.g. Results for: <tag>), so script can run in a victim's browser.
What happened on this run
----------------
Raw attacker HTML appeared in the document source.
Technical observations
----------------
• HTTP status: 200
• Query probe: <vulnhost-xss-probe>
Security impact
----------------
Session hijack, phishing, actions as the victim.
Recommended fix
----------------
HTML-encode all dynamic output; deploy Content-Security-Policy.
Attacker logs in, opens /tickets.php, and submits a new ticket whose body contains HTML/script markup.
XSS · stored_xss
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Persistent XSS in ticket bodies.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in, opens /tickets.php, and submits a new ticket whose body contains HTML/script markup.
2. On reload, the ticket list renders that body as raw HTML — any user viewing tickets executes the payload.
What happened on this run
----------------
Stored markup appeared unescaped in the ticket view.
Technical observations
----------------
• HTTP status: 200
• Stored probe: <vulnhost-stored-04ebc8>
Security impact
----------------
Persistent compromise of every user who views tickets.
Recommended fix
----------------
Encode on output, CSP, sanitize rich text with a safe library.
Attacker opens /debug.php directly in the browser without logging in.
Disclosure · debug_phpinfo
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Unauthenticated access to phpinfo().
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens /debug.php directly in the browser without logging in.
2. Full PHP configuration, extensions, and paths are displayed.
What happened on this run
----------------
phpinfo() output was publicly visible.
Technical observations
----------------
• HTTP status: 200
• Request: GET https://testi.compla.nl/debug.php
Security impact
----------------
Reconnaissance for version-specific exploits.
Recommended fix
----------------
Remove debug routes in production; restrict to localhost if needed.
Attacker sends POST /api/legacy.php with form field data= containing a serialized PHP object string.
Deserialization · unsafe_unserialize
Tap to view screenshot or rendered proof
Exploitable
What we tested
----------------
Unsafe PHP unserialize on attacker-controlled input.
How the attacker reproduced this (browser steps)
----------------
1. Attacker sends POST /api/legacy.php with form field data= containing a serialized PHP object string.
2. The API unserializes the blob and echoes object details in the response — gadget chains may lead to RCE.
What happened on this run
----------------
Response shows deserialized object (e.g. object(stdClass)).
Technical observations
----------------
• HTTP status: 200
• POST data: O:8:"stdClass":0:{}
• Request: POST https://testi.compla.nl/api/legacy.php
Security impact
----------------
Object injection and potential remote code execution.
Recommended fix
----------------
Use JSON instead of serialize(); never unserialize untrusted data.
Step 1 — Detect PHP: open /login.php. If you see a normal HTML login form, PHP is executing. If you see raw <?php source or a file download, PHP is not run...
Disclosure · php_files_forbidden
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Detect whether PHP runs on the host, then verify .php files that must not be public return Forbidden (not raw source or accidental execution).
How the attacker reproduced this (browser steps)
----------------
1. Step 1 — Detect PHP: open /login.php. If you see a normal HTML login form, PHP is executing. If you see raw <?php source or a file download, PHP is not running (static hosting).
2. Step 2a — If PHP is NOT running: try /pin.php, /index.php, /router.php in the browser. Each should return 403 Forbidden (or 404). If the server serves PHP source code or runs the script, that is a critical misconfiguration.
3. Step 2b — If PHP IS running: try /bootstrap.php and /lib/pin_gate.php. These must never be web-readable — expect 403/404. If you see PHP source or secrets, the document root is wrong or directory protection failed.
What happened on this run
----------------
Policy looks correct: PHP runtime was classified accurately and probed .php paths returned Forbidden or were not exposed (no source leak).
Technical observations
----------------
• PHP runtime active: yes
• Check mode: PHP is executing — app .php outside public/ must not be web-readable
• Protected responses: GET /bootstrap.php → HTTP 200; GET /lib/pin_gate.php → HTTP 200; GET /config/database.php → HTTP 200
Security impact
----------------
Raw .php on static hosts leaks credentials in source; exposed bootstrap/lib files leak app secrets and aid full compromise.
Recommended fix
----------------
Static hosts: block *.php in nginx/Apache or remove PHP files from the web tree. PHP hosts: document root = public/ only; deny access to lib/, config/, bootstrap.php; return 403 for dotfiles and parent paths.
Attacker opens https://your-domain/.env directly in the browser address bar — no login, no tricks.
Disclosure · direct_env
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Detect if .env is exposed at the web root (common when document root is the upload folder, not public/).
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens https://your-domain/.env directly in the browser address bar — no login, no tricks.
2. If the server document root includes the project folder (bootstrap.php level), Apache/nginx may serve the raw .env file.
3. The page shows plaintext lines such as PANEL_SECRET=, API_KEY=, and ADMIN_PASS= — the easiest possible secret leak.
What happened on this run
----------------
GET /.env did not return .env contents (404/403, blocked by server rules, or docroot correctly set to public/ only).
Technical observations
----------------
• HTTP status: 403
• Request: GET https://testi.compla.nl/.env (no session)
• Marker: not found
Security impact
----------------
Instant full credential and API key theft with a single URL; scanners hit this in seconds.
Recommended fix
----------------
Set document root to public/ only; deny dotfiles in nginx/Apache; never deploy .env inside the web tree; use env vars on the host instead.
The lab runner generates the standard EICAR antivirus test string on your PC (not shipped in the repo).
Upload · eicar_upload
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Verify uploads are scanned for malware using the harmless EICAR test file.
How the attacker reproduced this (browser steps)
----------------
1. The lab runner generates the standard EICAR antivirus test string on your PC (not shipped in the repo).
2. It logs in and POSTs the file to /upload.php (e.g. eicar_<id>.com) like a real user upload.
3. It then GETs /uploads/<filename> — if the exact EICAR marker is still there, nothing blocked it at upload or storage.
What happened on this run
----------------
Upload rejected, quarantined, or file stripped before it could be downloaded.
Technical observations
----------------
• Upload HTTP status: 200
• Filename: eicar_87c1b124.com
• Result: Upload rejected (AV/policy)
Security impact
----------------
Real malware would reach disk and backups; hosting panels are common malware distribution points.
Recommended fix
----------------
Scan uploads with ClamAV or cloud AV; block EICAR in CI; quarantine; never serve untrusted files from the web root.
Attacker logs in and POSTs to /upload.php with path= such as tenant-lab/../../public/uploads.
Upload · upload_path_traversal
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Write uploaded files outside the intended tenant folder using the path form field.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and POSTs to /upload.php with path= such as tenant-lab/../../public/uploads.
2. The server joins path + filename without canonicalization and may place files under public/uploads/ (web-readable).
What happened on this run
----------------
Path normalized, rejected, or file not web-accessible.
Technical observations
----------------
• Upload HTTP status: 200
• path field: tenant-lab/../../public/uploads
• GET /uploads/: 200
Security impact
----------------
Web shells or malware planted directly under the document root.
Recommended fix
----------------
Ignore client path; derive tenant from session; use realpath() and reject ..; store outside public/.
Attacker crafts a .zip with an entry like ../../../public/uploads/evil.txt (or a .php).
Upload · zip_slip
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Escape the extract directory by uploading a zip whose entries contain ../ paths (Zip Slip).
How the attacker reproduced this (browser steps)
----------------
1. Attacker crafts a .zip with an entry like ../../../public/uploads/evil.txt (or a .php).
2. They POST the archive to /tools/import.php; extractTo() runs without sanitizing entry paths.
What happened on this run
----------------
Paths sanitized, extraction disabled, or zip rejected.
Technical observations
----------------
• Upload HTTP status: 200
• Zip entry: ../../../public/uploads/zipslip_8173e8d4.txt
• GET proof: 200
Security impact
----------------
Arbitrary file write leading to RCE or overwrite of config.
Recommended fix
----------------
Resolve each entry with realpath(); reject ..; extract only basenames into a chrooted dir.
Attacker logs in and POSTs malicious XML to /tools/import-xml.php with a DOCTYPE and SYSTEM entity.
Injection · xml_xxe
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Read server files via XML external entities in config import.
How the attacker reproduced this (browser steps)
----------------
1. Attacker logs in and POSTs malicious XML to /tools/import-xml.php with a DOCTYPE and SYSTEM entity.
2. Parser expands entities (LIBXML_NOENT) and echoes content — file:// or php://filter may leak .env.
What happened on this run
----------------
Entities disabled, parser hardened, or input rejected.
Technical observations
----------------
• HTTP status: 200
• Request: POST /tools/import-xml.php (XXE entity)
Security impact
----------------
Disclosure of credentials and keys; SSRF in some parsers.
Recommended fix
----------------
Disable external entities; use libxml_disable_entity_loader patterns; prefer JSON config.
Attacker opens /uploads/ in the browser (scanner or manual).
Disclosure · directory_listing_uploads
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Enumerate uploaded filenames via directory listing on /uploads/.
How the attacker reproduced this (browser steps)
----------------
1. Attacker opens /uploads/ in the browser (scanner or manual).
2. Server returns Index of /uploads with file names — no login required.
What happened on this run
----------------
403/404 or empty index without file names.
Technical observations
----------------
• HTTP status: 200
• Request: GET /uploads/
Security impact
----------------
Leak of private filenames, shells, backups; aids further attacks.
Recommended fix
----------------
Disable Options +Indexes; serve uploads via controlled download script only.
Attacker requests /.git/HEAD (automated scanners do this constantly).
Disclosure · exposed_git
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Detect public .git metadata (common deployment mistake).
How the attacker reproduced this (browser steps)
----------------
1. Attacker requests /.git/HEAD (automated scanners do this constantly).
2. If deployed from git without excluding .git, ref: refs/heads/main is returned.
What happened on this run
----------------
404/403 or no git metadata at web root.
Technical observations
----------------
• HTTP status: 403
• Body preview: Forbidden
Security impact
----------------
Full source history recovery via git tools.
Recommended fix
----------------
Never deploy .git to web root; use CI artifacts; block /.git in nginx/Apache.
Attacker POSTs /tools/forgot.php with X-Forwarded-Host: attacker.example.
Header injection · host_header_reset
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Poison password-reset links using Host / X-Forwarded-Host.
How the attacker reproduced this (browser steps)
----------------
1. Attacker POSTs /tools/forgot.php with X-Forwarded-Host: attacker.example.
2. Reset URL in the response uses the attacker host — victim clicks and leaks tokens.
What happened on this run
----------------
Canonical host hard-coded; forwarded headers ignored.
Technical observations
----------------
• X-Forwarded-Host: attacker-cache.vulnhost-lab.example
Security impact
----------------
Account takeover via phishing reset links on a trusted domain name in email.
Recommended fix
----------------
Build URLs from configured APP_URL only; strip untrusted X-Forwarded-*.
What we tested
----------------
Inject response headers via CRLF in download filename.
How the attacker reproduced this (browser steps)
----------------
1. Attacker requests /tools/export.php?filename=lab.txt%0d%0aX-Lab-Injected:%20true.
2. Unsanitized filename breaks out of Content-Disposition and adds headers.
What happened on this run
----------------
CRLF stripped, filename encoded, or headers not injectable.
Technical observations
----------------
• X-Lab-Injected header: (absent)
Security impact
----------------
Session fixation via Set-Cookie injection, XSS via injected headers in proxies.
Recommended fix
----------------
Strip \r\n from header values; use RFC 5987 filename* encoding only.
After successful login, inspect Set-Cookie for PHPSESSID.
Session · session_cookie_insecure
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Session cookies should use HttpOnly and Secure flags.
How the attacker reproduced this (browser steps)
----------------
1. After successful login, inspect Set-Cookie for PHPSESSID.
2. Flags HttpOnly and/or Secure are missing on HTTPS deployments.
What happened on this run
----------------
Both flags present on session cookie.
Technical observations
----------------
• Set-Cookie (trunc):
• Missing HttpOnly: yes
• Missing Secure: yes
Security impact
----------------
Session hijack via XSS or network sniffing.
Recommended fix
----------------
session.cookie_httponly=1, session.cookie_secure=1 on HTTPS, SameSite=Lax/Strict.
Attacker sets victim's PHPSESSID, victim logs in, same id remains active.
Session · session_fixation
Tap to view screenshot or rendered proof
Blocked
What we tested
----------------
Session ID must change after authentication.
How the attacker reproduced this (browser steps)
----------------
1. Attacker sets victim's PHPSESSID, victim logs in, same id remains active.
2. Attacker reuses that id to hijack the authenticated session.
What happened on this run
----------------
session_regenerate_id(true) on login.
Technical observations
----------------
• Before: bef019cf3c1c2bfafa00697c28f7efd1
• After: 5b1f7388d68631e01699ccd0c0af51bf
Security impact
----------------
Account takeover without stealing password.
Recommended fix
----------------
Regenerate session id on privilege change; invalidate old sessions.
