Document dyndns command-injection fix and two remaining follow-ups

README's public-access table and "previously resolved" summary now
reflect the dyndns injection fix and the TSIG-permission regression it
uncovered. Adds two open TODO items found during that audit: the dyndns
app's lack of real per-user auth binding, and the fact that access
logging for every real vhost on this host is currently a no-op.

TODO.md

@@ -3,6 +3,36 @@
 Outstanding hardening items (see `README.md` for the full service overview).
 Nothing here is urgent; all are low-risk, no-downtime changes.
 
+- [ ] **dyndns app has no real per-user auth binding** — found 2026-07-20,
+      while fixing the command injection below.
+      `index.php`'s `pass == '_NO_PASS_'` check is a hardcoded magic
+      string, not a real per-user credential — there's nothing tying the
+      single shared Apache Basic Auth identity to *which* hostname label
+      gets updated. Any caller with valid dyndns credentials can update
+      any of the zone's 5 hostnames (`jens`, `kack`, `test`, `uschi`,
+      `vpn`), not just their own. Low severity today since apparently only
+      one person (`jens`) has credentials, but worth fixing before adding
+      any second dyndns user. Fix: either move to per-host TSIG-style
+      tokens, or add a static host-allowlist per `.htpasswd` user in the
+      PHP.
+
+- [ ] **dyndns/default-vhost access logging is a no-op** — found
+      2026-07-20, while investigating the command injection below.
+      `dyndns.jayfield.org`, `jayfield.org`, `www.jayfield.org`,
+      `mail.jayfield.org`, `web.jayfield.org`, and `cloud.jayfield.org`
+      have no `CustomLog` directive of their own, so requests to them
+      should fall back to the global `CustomLog ${APACHE_LOG_DIR}/access.log`
+      in `apache2.conf` — but that file had 0 lines when checked. Only
+      `default-ssl.conf`/`000-default.conf` explicitly set `CustomLog`.
+      Net effect: there's currently no access-log trail for any real
+      vhost on this host, which is exactly the evidence that would be
+      needed to rule out past abuse of things like the dyndns injection
+      above. Needs root-causing (global `CustomLog` not actually wired up
+      to these vhosts? logs going somewhere else? log rotation wiping it
+      right before checks?) and likely a per-vhost `CustomLog` added to
+      each site, matching the `default-ssl.conf`/`000-default.conf`
+      pattern.
+
 - [x] **OS command injection in the dyndns update scripts** — done 2026-07-20
       `/var/www/dyndns/nsupdate.php`, `nsupdate_ipv4.php`, and
       `nsupdate_ipv6.php` (used by both `index.php` and `nic/update.php`,