fix(security): close GHSA-g94x (cross-gallery photo read) + GHSA-pv6w (admin DB export) (stable) (#925)

* fix(security): close two access-control advisories (GHSA-g94x, GHSA-pv6w) (stable)

GHSA-g94x-8vv8-3c9f (HIGH) — the secure-image VIEW route
(/secure-images/:slug/secure/:photoId/:token) validated only the token
signature and took the gallery/photo from the URL, so a token minted on
any PUBLIC gallery read every other gallery's photos with no password
(its download sibling has verifyGalleryAccess; the view route can't —
it serves via <img src> with no header). Bind the token to its scope
instead: the URL photoId must equal the token's minted photoId (photos
belong to exactly one gallery, and minting is gallery-scoped), and the
gallery embedded in the token's sessionId must equal the URL gallery.

GHSA-pv6w-rj34-wj9v (MEDIUM) — GET /admin/backup/picpeak/export dumps
every table unredacted (bcrypt hashes, 2FA, SMTP/SSO/WhatsApp/webhook/S3
secrets) and was gated only by backup.create, which the built-in admin
role holds. Gate it behind super_admin, matching the restore side
(backup.restore, already admin-denied) and the masked config APIs.

Regression tests pin both: cross-gallery token reads 403 (photo and
gallery checks), backup export 403 for admin / passes for super_admin.

Stable port of #924. secureImages on stable has no reveal-mode block, so
only the token-binding checks are added; the backup export gate is
identical.

* fix(security): review follow-ups on the export gate (GHSA-pv6w)

- test: place the mocked export in its own mkdtemp dir. The route
  recursively deletes path.dirname(filePath) after download, so a stub
  in bare os.tmpdir() made the super_admin test wipe the whole temp
  root — other jest workers' DB files included (latent CI flake).
- ui: hide PicpeakExportCard from non-super_admins. The role keeps
  settings.view + backup.create, so after the gate its Download button
  always 403'd with a generic toast; gate the card on role super_admin
  to match the endpoint.

* fix(security): keep the token-mismatch audit values within varchar(20) (GHSA-g94x review)

image_access_logs.access_type is varchar(20) (migration 038), but
'token_gallery_mismatch' is 22 chars — on Postgres the audit write
threw value-too-long and logImageAccess swallowed it, so the security
event went unrecorded (the 403 still fired; log is best-effort). Shorten
to 'photo_mismatch' / 'gallery_mismatch' (14/16).

---------

Co-authored-by: Paul Nothaft <[email protected]>

backend/src/routes/adminBackup.js

@@ -1,7 +1,7 @@
 const express = require('express');
 const { db } = require('../database/db');
 const { adminAuth } = require('../middleware/auth');
-const { requirePermission } = require('../middleware/permissions');
+const { requirePermission, requireSuperAdmin } = require('../middleware/permissions');
 const { clearAdminAuthCookie } = require('../utils/tokenUtils');
 const { revokeToken } = require('../utils/tokenRevocation');
 const { triggerManualBackup, getBackupStatus, cleanupOldBackupRuns, getBackupManifest, validateBackupManifest } = require('../services/backupService');
@@ -139,7 +139,12 @@ router.post('/run', adminAuth, requirePermission('backup.create'), async (req, r
 // SECURITY: the file contains plaintext secrets (SMTP password, admin password
 // hashes, API keys). The download UI must warn before offering it. We surface
 // the flag as a response header too so the client can double-confirm.
-router.get('/picpeak/export', adminAuth, requirePermission('backup.create'), async (req, res) => {
+// Full-instance export dumps every table unredacted — bcrypt password
+// hashes, 2FA columns, and all integration secrets (SMTP/SSO/WhatsApp/
+// webhook/S3) in cleartext. The built-in `admin` role holds backup.create,
+// but is denied this data everywhere else (config APIs mask secrets as
+// ********). Gate the raw dump behind super_admin (GHSA-pv6w-rj34-wj9v).
+router.get('/picpeak/export', adminAuth, requireSuperAdmin(), async (req, res) => {
   const fsSync = require('fs');
   try {
     const includePhotos = req.query.includePhotos === 'true' || req.query.includePhotos === '1';

backend/src/routes/secureImages.js

@@ -137,6 +137,34 @@ router.get('/:slug/secure/:photoId/:token',
         return res.status(404).json({ error: 'Gallery not found' });
       }
 
+      // Bind the token to the gallery + photo it was minted for
+      // (GHSA-g94x-8vv8-3c9f). This route serves via <img src> with the
+      // token in the URL, so it can't require verifyGalleryAccess like the
+      // download sibling does. Instead enforce the scope already inside the
+      // token: it is minted for one photoId (and photos belong to exactly
+      // one gallery), and its sessionId records the minting gallery's id.
+      // Without this, a token minted on any PUBLIC gallery reads every other
+      // gallery's photos with no password.
+      const tokenPhotoId = Number(tokenValidation.data?.photoId);
+      if (!Number.isInteger(tokenPhotoId) || tokenPhotoId !== Number(photoId)) {
+        await secureImageService.logImageAccess(
+          photoId, event.id, req.clientInfo, 'photo_mismatch'
+        );
+        return res.status(403).json({ error: 'Token not valid for this photo' });
+      }
+      // Defense in depth: the sessionId embeds the gallery the token was
+      // minted for (`gallery_public_<id>_...` / `gallery_<id>_...`). Reject a
+      // token whose gallery is parseable and differs from this one.
+      const sessionEventId = Number(
+        (String(tokenValidation.data?.sessionId || '').match(/^gallery_(?:public_)?(\d+)_/) || [])[1]
+      );
+      if (Number.isInteger(sessionEventId) && sessionEventId !== Number(event.id)) {
+        await secureImageService.logImageAccess(
+          photoId, event.id, req.clientInfo, 'gallery_mismatch'
+        );
+        return res.status(403).json({ error: 'Token not valid for this gallery' });
+      }
+
       // Verify photo exists and belongs to event  
       const photo = await db('photos')
         .where({ id: photoId, event_id: event.id })