- IPv4-mapped cloud metadata (::ffff:169.254.169.254) previously fell through
the IPv4-mapped IPv6 detection block and returned the generic private-IP error
instead of the cloud-metadata error, making the two cases inconsistent
- The IPv4-mapped error path used ip.String() (the raw ::ffff:… form) directly
rather than sanitizeIPForError, potentially leaking the unsanitized IPv6
address in error messages visible to callers
- Now extracts the IPv4 from the mapped address before both the cloud-metadata
comparison and the sanitization call, so ::ffff:169.254.169.254 produces the
same "access to cloud metadata endpoints is blocked" error as 169.254.169.254
and the error message is always sanitized through the shared helper
- Updated the corresponding test to assert the cloud-metadata message and the
absence of the raw IPv6 representation in the error text
HTTP/HTTPS uptime monitors targeting LAN addresses (192.168.x.x,
10.x.x.x, 172.16.x.x) permanently reported 'down' on fresh installs
because SSRF protection rejects RFC 1918 ranges at two independent
checkpoints: the URL validator (DNS-resolution layer) and the safe
dialer (TCP-connect layer). Fixing only one layer leaves the monitor
broken in practice.
- Add IsRFC1918() predicate to the network package covering only the
three RFC 1918 CIDRs; 169.254.x.x (link-local / cloud metadata)
and loopback are intentionally excluded
- Add WithAllowRFC1918() functional option to both SafeHTTPClient and
ValidationConfig; option defaults to false so existing behaviour is
unchanged for every call site except uptime monitors
- In uptime_service.go, pass WithAllowRFC1918() to both
ValidateExternalURL and NewSafeHTTPClient together; a coordinating
comment documents that both layers must be relaxed as a unit
- 169.254.169.254 and the full 169.254.0.0/16 link-local range remain
unconditionally blocked; the cloud-metadata error path is preserved
- 21 new tests across three packages, including an explicit regression
guard that confirms RFC 1918 blocks are still applied without the
option set (TestValidateExternalURL_RFC1918BlockedByDefault)
Fixes issues 6 and 7 from the fresh-install bug report.
- Updated error variable names for clarity in DNS provider, import, logs, manual challenge, security, user, and other handlers.
- Improved error handling in services such as backup, credential, docker, mail, notification, security headers, and uptime services.
- Enhanced readability by using more descriptive variable names for errors in multiple locations across the codebase.
- Ensured consistent error handling practices throughout the application.
- Changed report title to reflect security audit focus
- Updated date and status to indicate approval for commit
- Enhanced executive summary with detailed validation results
- Included comprehensive test coverage results for backend and frontend
- Documented pre-commit hooks validation and known issues
- Added detailed security scan results, confirming absence of CVE-2025-68156
- Verified binary inspection for expr-lang dependency
- Provided risk assessment and recommendations for post-merge actions
- Updated compliance matrix and final assessment sections
- Improved overall report structure and clarity
- Updated UsersPage tests to check for specific URL formats instead of regex patterns.
- Increased timeout for Go coverage report generation to handle larger repositories.
- Cleaned up generated artifacts before running CodeQL analysis to reduce false positives.
- Removed outdated QA testing report for authentication fixes on the certificates page.
- Added final report confirming successful resolution of authentication issues with certificate endpoints.
- Deleted previous test output files to maintain a clean test results directory.
