POST /maintenance-pools/:id/assign-reward has no pool-ownership check — any MAINTAINER can drain any pool to an address of their choosing

Start with src/maintenance-pool/maintenance-pool.controller.ts and src/maintenance-pool/maintenance-pool.service.ts, then compare the caller checks in src/bounties/bounties.service.ts and src/milestones/milestones.service.ts. Trace how the authenticated user reaches the service and how pool ownership is loaded; also inspect the deposit route, since the issue asks for the same binding there. Done means unrelated maintainers cannot assign rewards or deposit against a pool, and specs verify forbidden requests leave the balance unchanged.

Location

• src/maintenance-pool/maintenance-pool.controller.ts:124 — MaintenancePoolController.assignReward
• src/maintenance-pool/maintenance-pool.service.ts:122 — MaintenancePoolService.assignReward

Problem

POST /maintenance-pools/:id/assign-reward is gated only by a global role check:

@UseGuards(JwtAuthGuard, RolesGuard)
@Roles(UserRole.MAINTAINER)
@Post(':id/assign-reward')
assignReward(
  @Param('id', new ParseUUIDPipe()) id: string,
  @Body() dto: AssignRewardDto,
) {
  return this.poolService.assignReward(
    id, dto.issueId, dto.amount, dto.recipientAddress, dto.recipientId,
  );
}

The controller never reads req.user at all, and MaintenancePoolService.assignReward takes no caller id. The pool is bound entirely from the URL :id.

Every other guard in assignReward is about the issue, not the caller:

• pool.status !== ACTIVE (service line 130)
• the issue exists and issue.isMaintenanceType (lines 133-139)
• pool.repositoryId === issue.repositoryId (line 140)
• pool.escrowId is set (line 145)
• balance sufficiency (lines 173-185)

None of them relate the caller to the pool. Both fields needed for the check already exist and are already loaded:

• MaintenancePool.createdById (src/common/entities/maintenance-pool.entity.ts:36)
• Repository.maintainerId (src/common/entities/repository.entity.ts:54), reachable through findOne's relations: { repository: true } (service line 51)

Compare BountiesService.refund (src/bounties/bounties.service.ts:257-265), which does exactly this binding for the equivalent bounty operation:

const isSponsor = bounty.sponsorId === callerUserId;
const isRepoMaintainer =
  !!bounty.issue?.repository?.maintainerId &&
  bounty.issue.repository.maintainerId === callerUserId;
if (!isSponsor && !isRepoMaintainer) throw new ForbiddenException(...);

and MilestonesService.fund (src/milestones/milestones.service.ts:73). The maintenance-pool payout path never got that treatment.

Why it matters

UserRole.MAINTAINER is a platform-wide role, not a per-repository one. Any single account holding it can pay out any other sponsor's maintenance pool, to a Stellar address it supplies in the request body, until the pool's balance reaches zero. The recipient address is fully attacker-controlled:

• recipientId is optional (AssignRewardDto, controller line 61-63), so EscrowService.assertRecipientsMatchUsers (src/escrow/escrow.service.ts:521) short-circuits on ids.length === 0 and performs no check at all.
• EscrowService.poolWithdraw then invokes the pool contract's withdraw for the supplied recipientAddress with no further authorization.

This is direct, unrecoverable fund theft, not a drift or bookkeeping bug — once withdraw lands on-chain, the funds are gone.

The repository-scoping guard at service line 140 does not help: it is skipped entirely when pool.repositoryId is null (a pool created with no repositoryId, which CreatePoolDto.repositoryId explicitly permits as optional), and when it does run it constrains which issue can be cited, not who may cite it.

Reproduction / failure path

1. Sponsor A creates a pool for their repository and deposits into it:
   • POST /maintenance-pools → pool P, createdById = A
   • POST /maintenance-pools/P/deposit with { "amount": "5000.0000000", "funderAddress": "G...A" } → P.balance = 5000
2. Attacker M holds UserRole.MAINTAINER but has no relationship to pool P or to its repository (repository.maintainerId !== M).
3. M picks any issue in P's repository that carries a maintenance label (so isMaintenanceType is true) — these are public, readable via GET /bounties / GitHub.
4. M calls, with their own JWT:

POST /maintenance-pools/P/assign-reward
{
  "issueId": "<that issue's uuid>",
  "amount": "5000.0000000",
  "recipientAddress": "G...ATTACKER",
  "issueId": "..."
}

Note recipientId is deliberately omitted so no user/address consistency check runs.

5. Every guard passes. The balance is decremented and EscrowService.poolWithdraw sends 5000 to G...ATTACKER.

@Throttle({ short: { limit: 1, ttl: 1000 } }) (controller line 119) only paces this; a single request suffices because amount is unbounded up to the balance.

Suggested fix

1. Extract the caller in the controller the way every sibling route does, and pass it down:

assignReward(
  @Param('id', new ParseUUIDPipe()) id: string,
  @Body() dto: AssignRewardDto,
  @Req() req: Request,
) {
  const callerUserId = (req.user as any).userId as string;
  return this.poolService.assignReward(id, callerUserId, dto.issueId, ...);
}

2. In assignReward, before any balance mutation, reject a caller who is neither the pool's creator nor the maintainer of the pool's repository — mirroring BountiesService.refund:

const isCreator = pool.createdById === callerUserId;
const isRepoMaintainer =
  !!pool.repository?.maintainerId &&
  pool.repository.maintainerId === callerUserId;
if (!isCreator && !isRepoMaintainer) {
  throw new ForbiddenException(
    'Only the pool creator or the repository maintainer can assign rewards from this pool',
  );
}

3. Apply the same binding to POST /maintenance-pools/:id/deposit, which is likewise bound only by :id.

4. Add controller and service specs covering the forbidden case: a MAINTAINER who is neither the pool creator nor the repository maintainer must receive 403 and the pool balance must be unchanged.

Consider also requiring recipientId (not optional) on AssignRewardDto so assertRecipientsMatchUsers always verifies the payout address against the user record on file, rather than trusting a bare address from the request body.