Un parche ya está en la rama maestra, pero la última versión publicada seguía sin incluirlo. El ajuste corrige cómo se validan permisos de claves API en tienda, cuenta y servidor.
BTCPay Server incorporó a su rama maestra una corrección para evitar que ciertas claves API con permisos amplios en una tienda superen los controles previstos para acciones de servidor o cuenta. El cambio, asociado al PR #7684 y atribuido a Nicolas Dorier, se fusionó el 19 de octubre.
La diferencia central es de alcance: una clave puede tener facultades extensas dentro de una tienda, sin que eso equivalga a autoridad global sobre toda la instalación. Según la información citada en el borrador, al 26 de octubre la versión 2.4.5 seguía siendo la última publicada y todavía no incluía el arreglo.
La corrección separa tienda, cuenta y servidor
BTCPay describe sus claves API como credenciales sujetas a permisos y a un ámbito de tienda. La corrección ajusta el mecanismo alternativo de autorización para que una concesión amplia asociada a una tienda solo sirva al evaluar permisos propios de esa tienda.
Con ese cambio, esa misma concesión deja de satisfacer verificaciones de nivel de servidor o de cuenta cuando la solicitud no tiene un alcance resuelto. El ajuste no convierte una clave de tienda en una credencial administrativa general; solo modifica cómo el sistema interpreta ese caso específico.
Las pruebas de regresión incluidas en el cambio muestran dos escenarios: una clave de administrador limitada a una tienda debe ser rechazada al intentar acceder a roles del servidor, y una clave de un usuario común debe fallar al tratar de eliminar esa misma cuenta de usuario. En ambos casos, el objetivo es impedir que el alcance dentro de una tienda sustituya los permisos requeridos fuera de ella.
La actualización seguía pendiente en la versión publicada
La descripción del cambio indica que las claves de administrador existentes sin alcance conservan su comportamiento. El ajuste se enfoca en cerrar la posibilidad de que una autorización amplia limitada a una tienda sea usada como sustituto de permisos exigidos en otro nivel.
El PR también añade una verificación para la creación de claves. Además de cumplir los requisitos del endpoint, el solicitante debe tener autorización para conceder los permisos que pide para la nueva credencial. La prueba incorporada al cambio verifica el rechazo de una solicitud que pretende crear una clave sin restricciones y sin alcance de tienda.
El repositorio separa dos vías de creación: una exige autoridad sin restricciones y sin alcance de tienda, y la otra requiere permisos para modificar la configuración del servidor. La nueva validación se suma después de esas condiciones iniciales, para impedir que una clave termine delegando privilegios mayores a los que puede otorgar.
Según la información de CryptoSlate citada en el borrador, al 26 de octubre la versión 2.4.5, publicada el 6 de octubre, seguía apareciendo como el lanzamiento más reciente. Eso implica que el parche fusionado el día 19 todavía no formaba parte de esa edición pública.
El PR público no reporta explotación confirmada, comerciantes afectados ni pérdidas asociadas con este problema. La documentación del proyecto recomienda pedir solo los permisos estrictamente necesarios para cada integración y revisar qué claves delegadas siguen activas, además de verificar que la versión instalada ya incluya el PR #7684.
Contenido redactado con asistencia de un LLM.
