Summary
Plane contains a stored cross-site scripting vulnerability in the public intake issue creation flow because submitted HTML is stored without the expected sanitization. An authenticated user may plant a malicious link in an eligible project, and a project member or viewer who activates it could execute JavaScript in their session and expose sensitive session data.
Plane contains a stored cross-site scripting vulnerability in the public intake issue creation flow because submitted HTML is stored without the expected sanitization. An authenticated user may plant a malicious link in an eligible project, and a project member or viewer who activates it could execute JavaScript in their session and expose sensitive session data.
Affected context
The issue occurs in Plane deployments where:
- The public intake feature is enabled for a project
- The project has a published DeployBoard
- User-supplied issue descriptions are persisted as HTML without effective sanitization
- Project members or viewers can access the affected intake item and interact with its content
Exploitation depends on a victim viewing and activating the planted content in a browser session with useful privileges.
The issue occurs in Plane deployments where:
- The public intake feature is enabled for a project
- The project has a published DeployBoard
- User-supplied issue descriptions are persisted as HTML without effective sanitization
- Project members or viewers can access the affected intake item and interact with its content
Exploitation depends on a victim viewing and activating the planted content in a browser session with useful privileges.
Exploit preconditions
- Attack surface: Authenticated public intake issue creation
- Required access: An authenticated Plane account; workspace membership may not be required when the intake configuration permits submission
- Target condition: A project with a published DeployBoard and intake enabled
- Trigger point: A project member or viewer opens the stored intake item and clicks the malicious link
- Why exploitation is possible: The submitted description HTML is persisted without the intended sanitization, while client-side link handling permits script execution in the viewer's session
- Attack surface: Authenticated public intake issue creation
- Required access: An authenticated Plane account; workspace membership may not be required when the intake configuration permits submission
- Target condition: A project with a published DeployBoard and intake enabled
- Trigger point: A project member or viewer opens the stored intake item and clicks the malicious link
- Why exploitation is possible: The submitted description HTML is persisted without the intended sanitization, while client-side link handling permits script execution in the viewer's session
Why this happens
The vulnerable flow writes attacker-controlled description_html directly during issue creation without applying the application's HTML sanitization and validation routine. This is a stored cross-site scripting condition mapped to CWE-79, because untrusted markup is later rendered and interpreted in another user's browser.
The issue also reflects an authorization weakness associated with CWE-862: the intake creation path permits users without the expected workspace membership relationship to introduce content into a project context. Together, insufficient authorization and incomplete output sanitization broaden the set of users who can plant persistent browser-executable content.
The vulnerable flow writes attacker-controlled description_html directly during issue creation without applying the application's HTML sanitization and validation routine. This is a stored cross-site scripting condition mapped to CWE-79, because untrusted markup is later rendered and interpreted in another user's browser.
The issue also reflects an authorization weakness associated with CWE-862: the intake creation path permits users without the expected workspace membership relationship to introduce content into a project context. Together, insufficient authorization and incomplete output sanitization broaden the set of users who can plant persistent browser-executable content.
Potential impact
- A victim's browser session may execute attacker-controlled JavaScript
- Long-lived API tokens or other accessible session data could be disclosed
- An attacker could perform actions available to the victim's account
- Project data may be modified, exposed, or poisoned
- The issue could facilitate further compromise of connected services
- A victim's browser session may execute attacker-controlled JavaScript
- Long-lived API tokens or other accessible session data could be disclosed
- An attacker could perform actions available to the victim's account
- Project data may be modified, exposed, or poisoned
- The issue could facilitate further compromise of connected services
General mitigation guidance
Mitigation generally focuses on enforcing both authorization and content-safety controls at the server boundary.
Common defensive patterns include:
- Apply a well-maintained HTML sanitizer such as the application's intended restricted sanitizer before persistence or rendering
- Prefer plain text or a narrowly defined markup allowlist for intake descriptions
- Treat all client-submitted HTML as untrusted, including fields named or represented as pre-rendered HTML
- Normalize and validate links, schemes, targets, and event-related attributes before storage and display
- Enforce workspace and project authorization independently of client-side visibility controls
- Use short-lived, scoped tokens and avoid exposing long-lived credentials to browser-accessible contexts
- Apply browser defenses such as an appropriate Content Security Policy as defense in depth
- Run intake and viewer roles with the minimum permissions required
Mitigation generally focuses on enforcing both authorization and content-safety controls at the server boundary.
Common defensive patterns include:
- Apply a well-maintained HTML sanitizer such as the application's intended restricted sanitizer before persistence or rendering
- Prefer plain text or a narrowly defined markup allowlist for intake descriptions
- Treat all client-submitted HTML as untrusted, including fields named or represented as pre-rendered HTML
- Normalize and validate links, schemes, targets, and event-related attributes before storage and display
- Enforce workspace and project authorization independently of client-side visibility controls
- Use short-lived, scoped tokens and avoid exposing long-lived credentials to browser-accessible contexts
- Apply browser defenses such as an appropriate Content Security Policy as defense in depth
- Run intake and viewer roles with the minimum permissions required
How teams detect issues like this
High-level detection can include:
- Static analysis searches for direct persistence of request-supplied HTML fields without sanitizer calls
- Code review checks that every create and update path applies consistent server-side validation
- Tests that submit disallowed tags, URL schemes, targets, and encoded markup through intake endpoints
- Authorization tests for users with no workspace membership and for project viewer roles
- Monitoring for suspicious links or unexpected HTML in issue descriptions
- Policy enforcement requiring approved sanitization libraries and centralized authorization checks
- Automated security review tools can help identify unsafe HTML sinks and missing access-control checks
High-level detection can include:
- Static analysis searches for direct persistence of request-supplied HTML fields without sanitizer calls
- Code review checks that every create and update path applies consistent server-side validation
- Tests that submit disallowed tags, URL schemes, targets, and encoded markup through intake endpoints
- Authorization tests for users with no workspace membership and for project viewer roles
- Monitoring for suspicious links or unexpected HTML in issue descriptions
- Policy enforcement requiring approved sanitization libraries and centralized authorization checks
- Automated security review tools can help identify unsafe HTML sinks and missing access-control checks
