Summary
Dromara Skyeye contains a server-side request forgery and authorization weakness in the OnlyOffice save callback. An unauthenticated attacker may provide URL and key values that cause the server to request internal resources and overwrite another user's stored file, with resulting data potentially retrievable through a file-view query.
Dromara Skyeye contains a server-side request forgery and authorization weakness in the OnlyOffice save callback. An unauthenticated attacker may provide URL and key values that cause the server to request internal resources and overwrite another user's stored file, with resulting data potentially retrievable through a file-view query.
Affected context
The issue occurs in deployments using the OnlyOffice save callback, particularly where the callback accepts caller-controlled url and key parameters without adequately restricting destinations or authorizing the referenced file. Risk is higher when the server can reach internal services and the callback can modify files belonging to other users.
The issue occurs in deployments using the OnlyOffice save callback, particularly where the callback accepts caller-controlled url and key parameters without adequately restricting destinations or authorizing the referenced file. Risk is higher when the server can reach internal services and the callback can modify files belonging to other users.
Exploit preconditions
- Attack surface: The OnlyOffice save callback and related file-view functionality
- Required access: Network access to the callback; authentication may not be required
- Trigger point: Processing attacker-supplied
urlandkeyparameters during a save operation - Why exploitation is possible: The server may fetch attacker-selected URLs and perform file operations without sufficiently validating the destination or confirming ownership and authorization
- Attack surface: The OnlyOffice save callback and related file-view functionality
- Required access: Network access to the callback; authentication may not be required
- Trigger point: Processing attacker-supplied
urlandkeyparameters during a save operation - Why exploitation is possible: The server may fetch attacker-selected URLs and perform file operations without sufficiently validating the destination or confirming ownership and authorization
Why this happens
The vulnerability combines server-side request forgery with missing authorization controls. A callback trusts client-controlled URL data when making outbound requests, matching CWE-918: Server-Side Request Forgery. Separately, file operations are not consistently bound to an authenticated user's permissions or an authorized object, allowing requests to affect another user's stored file.
The vulnerability combines server-side request forgery with missing authorization controls. A callback trusts client-controlled URL data when making outbound requests, matching CWE-918: Server-Side Request Forgery. Separately, file operations are not consistently bound to an authenticated user's permissions or an authorized object, allowing requests to affect another user's stored file.
Potential impact
- The server could access internal or otherwise restricted network services
- Sensitive response data may be exposed through application file-view functionality
- An attacker may overwrite files belonging to other users
- Stored documents or application content could be corrupted or replaced
- Internal services may be probed or abused through the vulnerable server
- The server could access internal or otherwise restricted network services
- Sensitive response data may be exposed through application file-view functionality
- An attacker may overwrite files belonging to other users
- Stored documents or application content could be corrupted or replaced
- Internal services may be probed or abused through the vulnerable server
General mitigation guidance
Mitigation generally focuses on reducing trust in callback parameters and enforcing authorization at every file operation.
Common defensive patterns include:
- Allowing outbound requests only to an explicit, tightly controlled destination set
- Rejecting loopback, link-local, private, metadata-service, and other restricted address ranges after DNS resolution
- Rechecking resolved destinations and preventing redirect-based policy bypasses
- Binding file identifiers and callback keys to authenticated users and authorized operations
- Applying deny-by-default authorization before reading, writing, or exposing stored files
- Separating outbound callback functionality from sensitive internal networks
- Limiting the service account's network and filesystem privileges
Mitigation generally focuses on reducing trust in callback parameters and enforcing authorization at every file operation.
Common defensive patterns include:
- Allowing outbound requests only to an explicit, tightly controlled destination set
- Rejecting loopback, link-local, private, metadata-service, and other restricted address ranges after DNS resolution
- Rechecking resolved destinations and preventing redirect-based policy bypasses
- Binding file identifiers and callback keys to authenticated users and authorized operations
- Applying deny-by-default authorization before reading, writing, or exposing stored files
- Separating outbound callback functionality from sensitive internal networks
- Limiting the service account's network and filesystem privileges
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis patterns where request parameters flow into HTTP clients or URL fetchers
- Code review checks for missing ownership validation around file identifiers and callback keys
- Tests using private, loopback, link-local, and redirecting destinations to verify egress controls
- Monitoring outbound requests from the application for unusual internal hosts, ports, or response sizes
- Authorization policy checks confirming that every file read and write is tied to the requesting principal
- Automated security review tools that identify SSRF data flows and missing access-control checks
Organizations can look for this weakness through:
- Static analysis patterns where request parameters flow into HTTP clients or URL fetchers
- Code review checks for missing ownership validation around file identifiers and callback keys
- Tests using private, loopback, link-local, and redirecting destinations to verify egress controls
- Monitoring outbound requests from the application for unusual internal hosts, ports, or response sizes
- Authorization policy checks confirming that every file read and write is tied to the requesting principal
- Automated security review tools that identify SSRF data flows and missing access-control checks
