risesoft-y9 WorkFlow-Engine CVE-2026-102616

Exploitation targets the getByIdAndYear function reached through the OAuth2 Resource Filter component of risesoft-y9 WorkFlow-Engine (versions up to 9.6.10), by supplying malicious input in the 'year' and/or 'processInstanceId' parameters, either of which is independently injectable. The vendor rates this as remotely reachable with no privileges (PR:N) and no user interaction, but the 'OAuth2 Resource Filter' component name suggests a valid OAuth2 access token may actually be required to reach the vulnerable endpoint - defenders should confirm whether the endpoint is exposed pre-authentication. Limiting factors: the product is a niche self-hosted workflow engine, so exposure depends on the instance being internet-reachable, and with no vendor patch available mitigation relies on WAF/input filtering or restricting endpoint access.

This is a low-to-moderate real-world risk despite being a publicly-exploitable, potentially unauthenticated SQL injection. The vendor CVSS 4.0 base score is 5.5 with all impact metrics rated Low (VC:L/VI:L/VA:L), reflecting a partial-impact SQLi rather than full database compromise or RCE, and the vendor vector already encodes E:P (proof-of-concept exploit maturity), consistent with the description's statement that 'the exploit is now public.' There is no CISA KEV listing and no EPSS score supplied, so there is no evidence of active or widespread exploitation - only that exploit code exists (do not conflate the two). The strongest aggravating factors are the network attack vector (AV:N), low attack complexity (AC:L), and PR:N in the vendor vector, meaning the vendor believes no authentication is required. However, there is a signal conflict: the affected component is described as the 'OAuth2 Resource Filter,' which normally implies a valid access token is needed to reach the endpoint, yet the vendor rated PR:N - this tension should be verified against the actual endpoint's auth requirements, as it materially changes exploitability. There is also no official patch or fixed version identified and the vendor did not respond to disclosure, so remediation depends on VulDB/researcher data only. Overall: a genuine, exploitable defect worth patching, but the Low impact ratings and niche product footprint keep it below high priority for most organizations.

A remote attacker sends a crafted request to the workflow engine's historic-process query endpoint, injecting SQL through the 'year' or 'processInstanceId' parameter consumed by getByIdAndYear in CustomHistoricProcessServiceImpl.java. Because the sink is injectable at two independent positions, the attacker can read or partially manipulate workflow/process data in the backing database. Public exploit code (POC) is already available per the disclosure and the linked VulDB/GitHub write-up.