Frappe Learning CVE-2025-62779

Exploitation requires an authenticated account with permission to create or edit a Job posting in Frappe Learning (2.39.1 and earlier), since the injection point is the Job Form input fields. Per the patch, only string fields OTHER than 'description' were unescaped and vulnerable. Execution further requires a second user (e.g., another learner or administrator) to view the affected Job Card, so the attack is gated by victim user interaction (UI:P) and does not fire automatically. These factors - authenticated access, limited vulnerable fields, and required victim viewing - substantially constrain real-world impact despite network reachability.

All signals converge on this being a genuinely low-priority issue rather than a high-CVSS flaw masquerading as low risk - the inputs are internally consistent. The vendor-assigned CVSS 4.0 base score is only 1.2, driven by AV:N (network-reachable web app) but offset heavily by PR:L (attacker must hold an authenticated account), UI:P (a victim must actively view the malicious content), and impact confined to the subsequent system (SC:L/SI:L) with zero impact on the vulnerable system itself (VC:N/VI:N/VA:N) - consistent with a stored XSS that only executes in another user's browser. EPSS reinforces this: 0.18% probability at the 7th percentile indicates negligible likelihood of exploitation activity. There is no CISA KEV listing and no public exploit identified, so this is not under active exploitation. No SSVC decision data was provided in the input. No signals conflict: low EPSS, no KEV, no POC, low CVSS, and an authenticated+interaction-gated stored XSS all agree this is a minor, defense-in-depth fix rather than an urgent remediation priority.

An authenticated user with access to create or edit a Job posting enters HTML/JavaScript into a Job Form input field (any string field other than 'description'). When another user or administrator later views the resulting Job Card in the Frappe Learning frontend, the injected script executes in their browser session. No public exploit code is identified at the time of analysis, and the attack requires an authenticated account plus a victim viewing the crafted entry.