Pleasanter CVE-2025-61931

Exploitation requires an authenticated account with at least low privileges (PR:L) sufficient to create or edit a record's Body, Description, or Comments fields - the exact user-controllable sinks named in the advisory. It further requires victim interaction (UI:A): a second logged-in user must open and render the record containing the stored payload, so the attack cannot fire without a target viewing the poisoned content. These two factors - mandatory authentication and mandatory victim viewing - meaningfully limit real-world risk and make this most relevant to multi-user Pleasanter deployments where a low-trust user can seed content consumed by higher-privileged users.

This is a medium-severity stored XSS (CVE-2025-61931, CWE-79) in the Pleasanter no-code business platform, and the signals consistently point to a genuine-but-limited priority rather than a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:A) shows network reach and low complexity but requires an authenticated attacker (PR:L) AND victim interaction (UI:A), and the impact is confined to the subsequent system with only low integrity/confidentiality effect (SC:L/SI:L, VC/VI/VA all N) - consistent with script execution in a victim's browser rather than compromise of the application itself. The EPSS score is low (0.18%, 7th percentile), indicating a low modeled probability of exploitation in the near term. This CVE is NOT in CISA KEV and there is no public exploit identified at time of analysis, so there is no active-exploitation or POC signal to elevate it. The signals do not conflict: a modest CVSS (4.8), low EPSS, no KEV, and no POC all agree this is a real hygiene issue for Pleasanter operators but not a mass-exploitation threat. The main residual risk is insider/low-privilege abuse against higher-privileged users who view attacker-controlled content.

An authenticated low-privileged Pleasanter user injects a malicious script into the Body, Description, or Comments field of a record. When another logged-in user (e.g., an administrator or colleague) opens that record, the stored script executes in their browser, allowing session-context actions or data theft within the app. No public exploit code is identified, and successful exploitation depends on a victim viewing the poisoned content.