rce_webmin

The report ends with an authenticated Webmin file-write-to-code-execution chain. Webmin’s CVE-2022-30708 advisory covers 1.991 and below, while the report claims 1.996. Treat that inconsistency as unresolved; a banner and a copied CVE label are insufficient proof that this exact flaw applies.

Review the program first

Use a source checkout whose revision you recorded:

python3 exploit.py --help
rg -n 'argparse|add_argument|upload|write|cron|delete|remove' exploit.py

Confirm the accepted arguments, vulnerable file operation, required module permissions, created files and cleanup behaviour. The helper’s filename is generic; identify it by the upstream project and revision. Do not run it merely because a password worked in the GUI.

Establish the actual boundary

A less-privileged Webmin user should be limited to its assigned modules and filesystem permissions. In a disposable lab, demonstrate the least invasive file operation needed to show that boundary failure; preserve before/after metadata and avoid replacing live system configuration as an initial test.

Success: evidence ties the unauthorised privileged write or process execution to the tested build and account permissions. The report’s callback is historical evidence, not a current universal version guarantee. Upgrade to a vendor-supported fixed release and audit untrusted Webmin users. Postman’s authenticated Package Updates issue is a separate Webmin vulnerability with separate prerequisites.

Separate the advisory from the copied walkthrough

Question	Evidence to collect
Which Webmin build is installed?	Administrative version view or local package metadata
Which account is used?	Webmin identity and configured Unix identity
Which modules are assigned?	Module ACLs and restrictions such as safe mode
Which operation crosses the boundary?	Request endpoint, submitted path and actual write result
What executes the modified file?	Load/trigger request and process identity

The original PoC identifies itself as a 1.991 safe-mode privilege escalation. Use the vendor’s security advisory and the specific source to explain applicability. The report’s 1.996 claim should remain qualified until reproduced against the actual installation.

Read the PoC as a sequence

The referenced script authenticates through session_login.cgi, submits a file-write request to settings-editor_write.cgi, and targets the Authentic Theme’s scripts.pl. Its follow-up login is part of the trigger sequence. A 302 response is what the script calls success; it is not independent proof of a privileged write or a launched process.

rg -n 'session_login|settings-editor|scripts\.pl|status_code|verify|system\(' exploit.py
python3 exploit.py --help

Do this on the review workstation. Running the unmodified script writes executable content into application files; it is not a read-only version check.

Argument reference for this exact project

Option	Input
`-u` / `--url`	Webmin base URL, including scheme and port
`-un` / `--username`	Webmin login name
`-pw` / `--password`	Login password
`-rh` / `--revhost`	Callback destination in the unmodified sample
`-rp` / `--revport`	Callback port in the unmodified sample

A modified marker-only proof may no longer need callback arguments. Keep its patch and digest with the evidence instead of pretending it is the unmodified upstream tool.

Diagnose access without performing the write

curl --cacert lab-ca.pem --dump-header webmin-headers.txt \
  --output webmin-login.html https://webmin.example.test:10000/

Establish TLS, proxy path and login reachability first. A valid Webmin login does not prove theme-editor access. Compare the account’s intended filesystem/module permissions with its observed access using a disposable lab installation.

Symptom	What it means to check
No `sid` cookie	Login rejected, MFA or a changed login flow
Certificate error	Correct CA trust and hostname; some PoC requests disable verification
Endpoint missing	Build/theme mismatch or proxy prefix
Redirect to login	Expired cookie or rejected request, not confirmed file write
File changed but no proof process	Trigger/load path and server logs
Proof runs as root	Tie it to module limits and the specific write, not just a banner

Restore application state

Take the original file and metadata backup before a lab write. Restore content, owner and mode from that backup, then verify normal application behaviour and absence of the proof marker. Do not clear the whole file as cleanup. Report the affected module, account restrictions, tested build and exact write target so the finding remains actionable even if the copied CVE label was wrong.

How attacks work. Examples use fictional lab values; replace placeholders only with values from the system you are testing.