BTCPay Server fusionó una corrección para impedir que ciertos permisos amplios limitados a una tienda satisfagan controles de acceso de servidor o cuenta. 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 no incluía el cambio.
***

• El PR #7684, atribuido a Nicolas Dorier, se fusionó en la rama maestra el 19 de octubre.
• La corrección separa las autorizaciones de tienda de las comprobaciones de permisos a nivel de servidor y cuenta.
• Según la información citada en el borrador, al 26 de octubre la versión 2.4.5, publicada el 6 de octubre, todavía no incluía el arreglo.

---

BTCPay corrige permisos de claves API, pero el parche aún no estaba publicado

El PR #7684 se fusionó el 19 de octubre. Impide que permisos limitados a una tienda habiliten acciones de servidor o cuenta.

Al 26 de octubre, la versión 2.4.5 no incluía el cambio. No se reportó… pic.twitter.com/UWiPb032p0

— Diario฿itcoin (@DiarioBitcoin) October 26, 2026

BTCPay corrigió permisos de claves API, pero el parche aún no llegaba a su última versión publicada

BTCPay Server, software que permite a los comerciantes aceptar pagos en Bitcoin, incorporó a su rama maestra una corrección para impedir que ciertas claves API con permisos amplios en una tienda superen los límites previstos para acciones de servidor o cuenta. El PR #7684, atribuido a Nicolas Dorier, se fusionó el 19 de octubre. El cambio aborda una distinción importante: una clave puede tener permisos extensos para operar en una tienda sin que eso equivalga a autoridad global sobre la instalación.

La corrección ya figura en el código de la rama maestra, pero eso no significa que estuviera disponible en una versión publicada. Según la información de CryptoSlate citada en el borrador, al 26 de octubre la lista de lanzamientos de BTCPay todavía mostraba la versión 2.4.5, fechada el 6 de octubre, como la más reciente. Esa versión antecede a la fusión del parche. Por ello, los administradores deben confirmar que una actualización posterior incluya el cambio antes de dar por cerrado el asunto.

Qué cambia en los límites de las claves

BTCPay describe sus claves API como credenciales para integraciones, restringidas por permisos y por tienda. Son dos límites distintos: los permisos indican qué acciones puede realizar una aplicación, mientras que el alcance de tienda delimita dónde puede actuar. La corrección aborda un caso en el que una concesión amplia asociada a una tienda podía tomarse en cuenta como alternativa al resolver una solicitud sin un alcance definido, incluso ante comprobaciones de nivel superior.

El PR #7684 ajusta ese mecanismo alternativo de autorización, conocido como fallback, para que aceptar una concesión de cualquier tienda solo sirva al comprobar permisos propios de una tienda. Así, una concesión de ese tipo deja de satisfacer verificaciones de servidor o de cuenta cuando la solicitud no tiene un alcance resuelto. El cambio no convierte cualquier clave de tienda en una credencial administrativa: modifica la manera en que el sistema evalúa esos permisos en un escenario específico.

Las pruebas de regresión que acompañan al cambio ilustran dos situaciones. En una, una clave de un administrador con permisos amplios, pero limitada a una tienda, debe recibir una denegación al intentar acceder a roles del servidor; en otra, la clave de un usuario común debe ser rechazada cuando intenta eliminar la cuenta de ese mismo usuario. Los ejemplos comprueban que la amplitud de las acciones autorizadas dentro de una tienda no basta, por sí sola, para conceder autoridad fuera de ese ámbito.

El rol de quien posee la clave también importa, en particular para el acceso a nivel de servidor. La lógica de la corrección no elimina la condición de que el propietario tenga privilegios de administrador cuando la operación los exige, ni establece que una credencial restringida a facturas pueda adquirir poderes administrativos. Por eso, el alcance de tienda, las concesiones asignadas a la clave y los privilegios de su propietario deben entenderse como controles relacionados, pero no intercambiables.

La descripción del cambio indica que las claves de administrador existentes sin alcance conservan su comportamiento. El objetivo es cerrar la posibilidad de que una autorización amplia limitada a una tienda sirva como sustituto de permisos requeridos en otro nivel, no alterar de manera general el funcionamiento de todas las credenciales administrativas. La corrección se enfoca en una ruta concreta de evaluación y no demuestra que todas las claves o instalaciones estuvieran expuestas del mismo modo.

Creación de claves y estado de la actualización

El cambio también agrega una verificación para la creación de claves: además de cumplir los requisitos propios del endpoint, el solicitante debe tener autorización para conceder los permisos que pide para la nueva credencial. Esta comprobación busca evitar que una llamada autorizada para crear claves termine produciendo otra con privilegios superiores a los que el solicitante puede otorgar. Una prueba incorporada al PR verifica el rechazo de una solicitud de ese tipo.

El caso probado involucra una clave de administrador limitada a la autoridad de configuración del servidor que solicita crear una clave sin restricciones y sin alcance de tienda. El sistema debe rechazarla porque la credencial solicitante no tiene capacidad para conceder esa combinación más amplia. La prueba no afirma que crear claves sea posible sin autorización; refuerza el control sobre los permisos que una clave puede delegar una vez que la solicitud cumple las condiciones iniciales.

BTCPay mantiene requisitos de entrada distintos para sus dos vías de creación de claves. El endpoint de autoservicio exige autoridad sin restricciones y sin alcance de tienda, mientras que el endpoint dirigido a usuarios por parte de un administrador requiere autoridad para modificar la configuración del servidor. El PR añade una comprobación posterior sobre los permisos que el solicitante intenta conceder, sin confundir esas condiciones de acceso con la nueva validación.

Según la información de CryptoSlate citada en el borrador, al 26 de octubre la versión 2.4.5 seguía apareciendo como el lanzamiento más reciente. Como se publicó el 6 de octubre, antecede a la fusión del parche del día 19. La información disponible en el borrador no identifica cuál fue la primera versión que incorporó la corrección ni señala una publicación posterior que ya la incluya.

El PR público tampoco reporta explotación confirmada, comerciantes afectados o pérdidas relacionadas con este problema. Esa ausencia de reportes no demuestra que todas las instalaciones estén libres de riesgo, pero sí impide presentar la situación como un incidente de explotación comprobada. La distinción es relevante para separar el alcance técnico del cambio de cualquier afirmación no sustentada sobre daños reales.

La documentación de BTCPay recomienda solicitar los permisos más estrechos que resulten útiles para cada integración. Los comerciantes pueden revisar qué claves delegaron, qué concesiones amplias conservan y qué privilegios tienen sus propietarios, para reducir la autoridad de cada credencial a las tareas que necesita. También conviene comprobar que la versión desplegada incluya el PR #7684: la fusión en la rama maestra, por sí sola, no confirma que un servidor en producción ya haya recibido el arreglo.