Apache OFBiz CVE-2026-81828

Requires an authenticated Apache OFBiz back-office user holding catalog permission (PR:L) who can edit a product-store survey's template location. The attacker sets an arbitrary URL - internal network address, cloud-metadata endpoint, or file:// path - as the survey's template location; SurveyWrapper.getTemplate then fetches and FreeMarker-compiles it with no scheme or host validation (unlike the sibling loaders ScreenFactory, FormFactory, GridFactory, MenuFactory, TreeFactory, ThemeFactory, which validate first). Limiting factors: exploitation is gated behind a trusted catalog back-office role (not anonymous), affects only OFBiz 24.09 before 24.09.08, and disclosure is realized when a shopper subsequently loads the affected product-store survey. No special non-default feature toggle is needed beyond the normal survey-configuration capability.

Signals point to a real but bounded priority rather than an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, base 8.1 High) shows network-reachable, low-complexity exploitation, but PR:L means an authenticated back-office account holding catalog permission is required - not an anonymous internet attacker. EPSS is low at 0.18% (8th percentile), and the vulnerability is NOT on the CISA KEV list, so there is no evidence of active exploitation; this is consistent with the low EPSS. No SSVC decision string was supplied, but the vuln.today Decision label is 'this_week', which aligns with a High-severity, patch-available flaw that is not yet weaponized. The signals are internally consistent: high CVSS severity driven by confidentiality impact, offset by a meaningful privilege prerequisite and low exploitation probability. The main caveat is the privilege gating - an attacker must already hold a trusted catalog role, so real-world risk concentrates in environments with many back-office users, weak role hygiene, or exposed/compromised staff accounts. Treat as a scheduled-patch priority (this week), not a drop-everything emergency.

An authenticated back-office user with catalog permission edits a product-store survey and sets its template location to an attacker-controlled URL such as a cloud metadata endpoint (e.g. http://169.254.169.254/...), an internal service, or a local file via file://. SurveyWrapper.getTemplate calls URL.openStream() on that location with no scheme or host validation and compiles the fetched content as a FreeMarker template; the result is rendered into the HTTP response of any shopper who later loads that survey, making the disclosure non-blind. No public exploit identified at time of analysis - only vendor and oss-security advisories are referenced.