Summary
Cal.com (calcom/cal.diy) before 5.9.9 is affected by a critical unauthenticated remote code execution issue inherited from its bundled Next.js version, where React Server Components (RSC) request handling deserializes attacker-controlled input.
By sending a crafted RSC request, a remote attacker can trigger arbitrary code execution during server-side processing without authentication or user interaction.
Cal.com (calcom/cal.diy) before 5.9.9 is affected by a critical unauthenticated remote code execution issue inherited from its bundled Next.js version, where React Server Components (RSC) request handling deserializes attacker-controlled input.
By sending a crafted RSC request, a remote attacker can trigger arbitrary code execution during server-side processing without authentication or user interaction.
Affected context
This vulnerability affects Cal.com deployments using versions prior to 5.9.9 that rely on the bundled Next.js framework for handling React Server Components (RSC) requests.
The issue appears when servers accept and process RSC traffic over HTTP/HTTPS, and the underlying Next.js runtime deserializes and evaluates data from these requests on the server.
Environments where Cal.com is exposed to the internet and where RSC endpoints are reachable are particularly at risk, especially when additional isolation or sandboxing of server-side execution is not enforced.
This vulnerability affects Cal.com deployments using versions prior to 5.9.9 that rely on the bundled Next.js framework for handling React Server Components (RSC) requests.
The issue appears when servers accept and process RSC traffic over HTTP/HTTPS, and the underlying Next.js runtime deserializes and evaluates data from these requests on the server.
Environments where Cal.com is exposed to the internet and where RSC endpoints are reachable are particularly at risk, especially when additional isolation or sandboxing of server-side execution is not enforced.
Exploit preconditions
- Attack surface: Network-exposed Cal.com instances handling React Server Components (RSC) traffic.
- Required access: None; exploitation can be performed by an unauthenticated remote attacker.
- Trigger point: Delivery of a specially crafted RSC request that reaches the vulnerable Next.js RSC handler.
- Why exploitation is possible: The RSC request processing logic deserializes and interprets attacker-controlled data in a way that allows it to influence server-side code execution, enabling arbitrary code to run within the application runtime.
- Attack surface: Network-exposed Cal.com instances handling React Server Components (RSC) traffic.
- Required access: None; exploitation can be performed by an unauthenticated remote attacker.
- Trigger point: Delivery of a specially crafted RSC request that reaches the vulnerable Next.js RSC handler.
- Why exploitation is possible: The RSC request processing logic deserializes and interprets attacker-controlled data in a way that allows it to influence server-side code execution, enabling arbitrary code to run within the application runtime.
Why this happens
The root cause aligns with CWE-94: Improper Control of Generation of Code ('Code Injection').
The Next.js React Server Components (RSC) handler deserializes inbound data and treats aspects of that data as instructions or structures that influence server-side execution, without sufficiently constraining or validating what can be expressed.
Because RSC processing is tightly coupled with server-rendered logic, this trust in external input allows crafted payloads to shape code paths or code generation in ways the framework did not intend, ultimately enabling arbitrary code execution.
Cal.com inherits this insecure pattern by bundling the affected Next.js version and exposing the vulnerable RSC request pipeline in its server environment.
The root cause aligns with CWE-94: Improper Control of Generation of Code ('Code Injection').
The Next.js React Server Components (RSC) handler deserializes inbound data and treats aspects of that data as instructions or structures that influence server-side execution, without sufficiently constraining or validating what can be expressed.
Because RSC processing is tightly coupled with server-rendered logic, this trust in external input allows crafted payloads to shape code paths or code generation in ways the framework did not intend, ultimately enabling arbitrary code execution.
Cal.com inherits this insecure pattern by bundling the affected Next.js version and exposing the vulnerable RSC request pipeline in its server environment.
Potential impact
- Remote attackers may execute arbitrary code within the Cal.com server process.
- Attackers could access, modify, or delete application data handled by Cal.com.
- Compromise of user accounts and meeting data, including schedules, contact details, and integration tokens.
- Lateral movement within the hosting environment or infrastructure, depending on the server's permissions and network reach.
- Potential installation of backdoors, web shells, or persistence mechanisms on the affected server.
- Remote attackers may execute arbitrary code within the Cal.com server process.
- Attackers could access, modify, or delete application data handled by Cal.com.
- Compromise of user accounts and meeting data, including schedules, contact details, and integration tokens.
- Lateral movement within the hosting environment or infrastructure, depending on the server's permissions and network reach.
- Potential installation of backdoors, web shells, or persistence mechanisms on the affected server.
General mitigation guidance
Mitigation generally focuses on reducing the ability of untrusted input to influence server-side code execution and on hardening the environment where such code runs.
Pattern-based mitigations include:
- Favor RSC and server-rendering patterns that do not deserialize opaque or loosely-typed structures from client input, and avoid treating client data as executable instructions or configuration.
- Introduce strict validation and schema enforcement for any serialized protocol used between client and server, ensuring that only expected, strongly-typed data structures are accepted.
- Employ defense-in-depth around server-side rendering pipelines, such as isolating rendering processes, using restricted sandboxes or containers, and running with least-privilege OS and runtime permissions.
- Segment network access for the application server so that even if arbitrary code execution occurs, access to databases, internal services, or secrets is limited.
- Centralize security controls around template and component execution to ensure that any future dynamic code or template evaluation complies with a narrow, well-reviewed pattern.
Mitigation generally focuses on reducing the ability of untrusted input to influence server-side code execution and on hardening the environment where such code runs.
Pattern-based mitigations include:
- Favor RSC and server-rendering patterns that do not deserialize opaque or loosely-typed structures from client input, and avoid treating client data as executable instructions or configuration.
- Introduce strict validation and schema enforcement for any serialized protocol used between client and server, ensuring that only expected, strongly-typed data structures are accepted.
- Employ defense-in-depth around server-side rendering pipelines, such as isolating rendering processes, using restricted sandboxes or containers, and running with least-privilege OS and runtime permissions.
- Segment network access for the application server so that even if arbitrary code execution occurs, access to databases, internal services, or secrets is limited.
- Centralize security controls around template and component execution to ensure that any future dynamic code or template evaluation complies with a narrow, well-reviewed pattern.
How teams detect issues like this
Detection efforts can target both the underlying insecure patterns and signs of active exploitation.
High-level strategies include:
- Static analysis rules that look for unsafe deserialization or code-evaluation semantics within server-side rendering and RSC handling code, including frameworks that process serialized component trees.
- Code review checklists that call out any mechanism where inbound serialized data is used to determine which server-side components or functions are invoked, especially when reflection or dynamic loading is involved.
- Runtime monitoring for unusual patterns such as unexpected subprocess creation, file writes from the application process, or atypical network connections originating from the Cal.com/Next.js server.
- Centralized logging of RSC-related endpoints and payload sizes, followed by anomaly detection or alerting on suspicious requests (e.g., highly structured or unusually large serialized component data).
- Use of automated application security testing (SAST/DAST) tools that can recognize deserialization abuse and code injection signatures in Node.js/Next.js ecosystems and flag them during CI/CD.
Detection efforts can target both the underlying insecure patterns and signs of active exploitation.
High-level strategies include:
- Static analysis rules that look for unsafe deserialization or code-evaluation semantics within server-side rendering and RSC handling code, including frameworks that process serialized component trees.
- Code review checklists that call out any mechanism where inbound serialized data is used to determine which server-side components or functions are invoked, especially when reflection or dynamic loading is involved.
- Runtime monitoring for unusual patterns such as unexpected subprocess creation, file writes from the application process, or atypical network connections originating from the Cal.com/Next.js server.
- Centralized logging of RSC-related endpoints and payload sizes, followed by anomaly detection or alerting on suspicious requests (e.g., highly structured or unusually large serialized component data).
- Use of automated application security testing (SAST/DAST) tools that can recognize deserialization abuse and code injection signatures in Node.js/Next.js ecosystems and flag them during CI/CD.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
| github. | github.com/ |
| vulncheck. | vulncheck.com/ |
