Worked investigation · OpenWrt · AArch64
What does uHTTPD execute for a CGI request?
r2b put process launch first in a stripped AArch64 package. The first verifier pass missed an indirect call. A short follow-up and the pinned source showed normal CGI dispatch. The remaining question belongs to the deployed router.
uHTTPD calls execl for normal CGI dispatch. The source shows a direct interpreter or script launch. It does not build a shell command, and this package does not show a vulnerability.
01 · WHAT R2B FOUND
Start at process launch.
The quick brief put execl and fork in the first capsule. That made one narrow follow-up available: which static callers reach execl?
Process launch / child control · score 93
execl
fork
next: r2b verify ./uhttpd --import execl --json
The score orders candidates. It does not measure severity, confidence, or maliciousness.
02 · THE SOURCE
The source shows normal CGI dispatch.
Path lookup
uHTTPD resolves the request under its document root and checks whether the path belongs to the CGI prefix or an interpreter mapping.
Process setup
The server creates pipes, forks, redirects stdin and stdout, and prepares CGI environment variables.
Direct launch
The child changes to the document root and calls execl on the interpreter or script path. It does not build a shell command.
03 · WHERE AUTOMATION STOPPED
The first verifier pass missed the caller.
radare2 reported a data reference to reloc.execl. The adapter kept only call xrefs, so it never scanned forward to the nearby AArch64 blr x4.
r2b verify ./uhttpd --import execl --json
# {"verdicts": []}
The empty array exposed missing coverage. It did not prove there were no callers. That pattern now has a regression check; the same command finds fcn.000092e4 at 0x9384. The original result stays in the record.
THE DEPLOYMENT CHECK
Who can write the CGI paths this server is allowed to execute?
Check no_symlinks, interpreter mappings, filesystem ownership, overlays, and update scripts. The package alone cannot answer that.