August 25 Security Briefing: OneUptime, fast-uri, and Micrometer Updates

This briefing covers three software-security topics that were newly published or assigned CVE records on August 24, 2026. Their shared lesson is not simply that older versions are risky. Each issue sits at a boundary: whether public and authenticated OneUptime surfaces share an origin, whether a URI policy check and the eventual network destination refer to the same host, and whether tracking state is released when an asynchronous HTTP request fails before a response arrives.

Priorities depend on exposure. Internet-facing OneUptime deployments should review public status-page and realtime paths first. Node.js services that normalize user-controlled URLs before redirects, webhooks, or outbound requests should inventory fast-uri and its call sites. Java services combining Micrometer with Apache HttpAsyncClient should correlate pre-response connection failures with JVM heap growth.

Research Window and Selection

The fixed research window ran from August 24 at 09:00 through August 25 at 08:59 Korea time. A comparison against public, scheduled, and private SecuNote posts found no prior article covering these products with the same search intent or remediation path. They are also distinct from the justhtml, StackGres, and Tenda topics in the August 24 briefing and from the Fabrik, Mailgun, and WS Form standalone articles published on August 23.

Three OneUptime advisories were grouped as one operational trust-boundary topic. Two fast-uri CVEs were grouped because they converge on the same fixed releases and the same hostname-consistency checks. Micrometer was selected because its CVE record entered the window and the official Spring advisory provides precise affected configurations, fixed releases, and replacement instrumentation paths.

OneUptime Authentication and Status-Page Boundaries

OneUptime published advisories affecting status pages, the public realtime endpoint, and notification-channel verification. The highest-severity issue concerns tenant-controlled JavaScript and raw header or footer HTML running from the same application origin as dashboards, APIs, accounts, and administrative interfaces. If a logged-in user visits an attacker-controlled status page, same-origin script can make authenticated API requests and read the responses with the victim's ambient cookie. This is a cross-tenant origin-isolation failure, not merely a customization concern.

Versions before 12.0.15 are affected by the status-page issue, and 12.0.15 contains the fix. Operators should review both edit permissions and hosting boundaries. A custom status-page domain does not by itself remove a fallback path served from the primary host. Until the upgrade is deployed, minimize custom-script and raw-HTML privileges and keep user-controlled status content on an origin that does not receive application authentication cookies.

A second advisory links OneUptime's public realtime path to CVE-2026-69185 in socket.io-parser. A malformed binary event can leave reconstruction state installed so later binary frames accumulate in memory. Because the default realtime path parses traffic before application authentication, the condition can lead to repeatable memory exhaustion of the shared App, API, and realtime service. OneUptime 12.0.14 and later include the corrected parser; connection and frame limits remain useful defense in depth.

The third advisory addresses stable six-digit verification codes used for email, SMS, voice-call, and WhatsApp notification channels without expiry, failed-attempt counting, lockout, rotation, or route-level rate limiting. A low-privilege authenticated user could repeatedly try the small code space against a channel row created with someone else's contact detail. This issue is also fixed in 12.0.14. Deploying 12.0.15 or later resolves all three version boundaries in one upgrade target.

• Confirm the running OneUptime version and container image tag
• Check whether fallback status pages share an origin with dashboards and APIs
• Minimize custom JavaScript and raw HTML editing privileges
• Review pre-auth handling and limits on the public realtime WebSocket path
• Upgrade to 12.0.15 or later and regression-test status pages, channels, and realtime traffic

Two fast-uri Host-Interpretation Flaws

CVE-2026-75899 and CVE-2026-75931 were published as CVE records on August 24. Both can make the hostname observed during a policy check differ from the hostname used after normalization or resolution. Exposure is highest where untrusted URLs feed server-side requests, redirect validation, webhook delivery, origin checks, or hostname allowlists and blocklists.

CVE-2026-75899 is a double-decoding issue. Percent escapes in a hostname may be decoded during parsing and again during authority recomposition. A nested encoded hostname can therefore become an internal or loopback destination after a single normalize or resolve operation, creating an SSRF and host-policy-bypass primitive. Affected ranges are 2.4.1 through 2.4.4, 3.1.2 through 3.1.5, and 4.0.0 through 4.1.2.

CVE-2026-75931 concerns scheme-relative references such as //host/. fast-uri canonicalized a hostname to ASCII when a scheme was explicitly present, but the resolve path did not apply the same treatment when the effective scheme came from a base URI. Its own parse, resolve, normalize, and equal entry points could therefore disagree about the same host, allowing a policy decision on one representation and network use of another.

Both issues are fixed in 2.4.5, 3.1.6, and 4.1.3. Inventory direct and transitive dependencies in the actual lockfile, then verify that the built artifact contains the intended fixed release. Regression tests should confirm that policy checks, normalization, resolution, and the final outbound-request layer observe the same canonical host. Network controls that block internal, loopback, and link-local destinations provide an additional boundary but do not replace the package update.

• Inventory direct and transitive fast-uri releases in lockfiles
• Locate user-controlled URLs that reach requests, redirects, or webhooks
• Compare canonical hosts before and after policy enforcement
• Upgrade the active release line to 2.4.5, 3.1.6, or 4.1.3 or later
• Recheck egress restrictions for internal, loopback, and link-local destinations

Micrometer Asynchronous-Request Memory Leak

CVE-2026-59295 affects Micrometer instrumentation of Apache HttpAsyncClient. When an asynchronous request fails before any response is received—through a connection reset, timeout, or socket failure—the request's tracking state is not removed. Repeated failures can produce an unbounded JVM heap leak and eventually an OutOfMemoryError crash. The relevant configuration combines a vulnerable micrometer-core release with Apache HttpAsyncClient 4.x or 5.x and MicrometerHttpClientInterceptor.

The Spring advisory lists Micrometer 1.17.0, 1.16.0 through 1.16.6, 1.15.0 through 1.15.12, 1.14.0 through 1.14.16, and 1.9.18 and earlier as affected. OSS fixes are available in 1.17.1 and 1.16.7, while 1.15.13, 1.14.17, 1.9.19, and some point releases are distributed through enterprise support. Choose the fix that matches the supported release line rather than applying an ambiguous 'latest' label.

For Apache HTTP Client 5.6 and later, Spring recommends the httpclient5-observation module, which supersedes the vulnerable Micrometer instrumentation. With HTTP Client 5.x and Micrometer 1.12 or later, ObservationExecChainHandler is another non-vulnerable path that handles terminal outcomes correctly. Because changing instrumentation can alter metric names, tags, and dashboards, include observability regression tests in the migration.

If an immediate upgrade is constrained, identify untrusted or unreliable outbound endpoints and reduce the accumulation rate with conservative timeouts and concurrency controls. Those controls are temporary layers because the defect is retained tracking state. During incident analysis, correlate heap growth, post-GC retention, and request metrics with pre-response failures instead of relying on repeated restarts alone.

• Confirm use of MicrometerHttpClientInterceptor with Apache HttpAsyncClient
• Map the active release line to an official fixed version and support channel
• Observe heap and post-GC retention during resets and timeouts
• Evaluate httpclient5-observation or ObservationExecChainHandler where applicable
• Validate memory stability and metric continuity after remediation

Operator Check Sequence

Treat these as three different runtime boundaries rather than one generic patch batch. First, confirm deployed versions from assets, SBOMs, and lockfiles. Second, map the features that meet the affected conditions: OneUptime public surfaces, fast-uri processing of untrusted URLs, and Micrometer instrumentation of asynchronous HTTP requests. Third, stage the official fixed release and test both function and boundary behavior. Finally, verify the running image, bundled dependency, and operational metrics after production rollout.

1. Confirm exact products and versions from runtime evidence
2. Rank exposure by public access, untrusted URL flow, and request-failure frequency
3. Prepare OneUptime 12.0.15+, fast-uri 2.4.5/3.1.6/4.1.3+, and the applicable Micrometer fix
4. Regression-test origin isolation, canonical host consistency, and memory stability
5. Recheck runtime versions, logs, and metrics and preserve the change record

Version checks are the starting point. Operational priority comes from tracing how public paths, untrusted URLs, and pre-response failures enter the running system.