Open Source POS CVE-2025-68434

Exploitation requires that an authenticated OSPOS administrator (running an affected build, version 3.4.0 up to but not including 3.4.2) be socially engineered into visiting an attacker-controlled web page while holding a valid logged-in session; this UI:R dependency is the primary limiting factor. The underlying technical precondition is that the 'csrf' filter remains disabled in app/Config/Filters.php - which is the default state for the vulnerable versions, so no non-default configuration is needed on the victim side. The attacker needs no account or credentials on the target (PR:N) and no network position beyond getting the admin to load a URL. The documented workaround (manually uncommenting the CSRF filter) mitigates the flaw but is noted by the vendor to risk breaking the Sales module due to token-synchronization issues unless the full 3.4.2 patch is applied.

Multiple signals align to make this a credible, above-average-priority issue for anyone actually running OSPOS, though not a mass-internet emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8 High) reflects a network-reachable, low-complexity flaw needing no attacker privileges but requiring user interaction - specifically a logged-in administrator visiting an attacker-controlled page. The SSVC-style read is: exploitation = public PoC available (not confirmed in-the-wild), automatable = partial (the attacker cannot force an admin to visit, but the forged request itself is trivially scripted), technical impact = total (silent creation of a full Administrator account = complete takeover). Publicly available exploit code exists, and the source-code diff independently confirms root cause (CSRF filter was explicitly commented out in app/Config/Filters.php), which raises confidence that the PoC works as described. No EPSS score was provided in the input, so exploitation probability cannot be quantified; this should be verified. This is NOT in CISA KEV, so there is no evidence of active, widespread exploitation - the realistic threat is targeted social-engineering of an administrator rather than mass scanning. The one tempering factor versus the raw 8.8 is the mandatory UI:R gate: exploitation depends entirely on luring an authenticated admin, so real-world risk scales with how exposed/tricked a given deployment's admins are.

An attacker hosts a malicious web page containing a hidden auto-submitting form (or XHR) that POSTs to the OSPOS user/employee-creation endpoint. They send the link to a logged-in administrator via phishing; when the admin opens it, their authenticated browser silently submits the request and a new attacker-controlled Administrator account is created. A public PoC for this exact 'unauthorized administrator creation' flow is available, lowering the skill required to weaponize it.