Qué es FOSSBilling y en qué estado está realmente
Qué es FOSSBilling y en qué estado está realmente
Vendes hosting, licencias de software, descargas de pago o cualquier servicio con renovación periódica. Cada mes tienes que emitir facturas, cobrarlas, avisar al que no pagó, suspender al que sigue sin pagar, aprovisionar la cuenta del que sí pagó y atender el ticket del que no entiende su factura. Ese conjunto de tareas es lo que un sistema de billing automatiza, y las opciones maduras del mercado cuestan entre 35 y 85 dólares al mes o entre 599 y 5.999 dólares de licencia perpetua.
FOSSBilling es la alternativa libre a ese problema: Apache-2.0, sin límite de clientes, sin activación de licencia, con el código completo en tu servidor. También es software que su propio README declara beta, que en 2026 publicó 32 advisories de seguridad —cuatro de ellos críticos— y que se sostiene con un presupuesto anual de 791 dólares y un comité de cinco personas.
Las dos cosas son ciertas a la vez, y un curso que solo cuente la primera te va a costar dinero. Este capítulo pone los dos lados sobre la mesa con datos verificables: de dónde sale el proyecto, qué trae de fábrica, qué licencia tiene realmente, cuál es su historial de seguridad, quién lo mantiene y cómo se compara con las alternativas comerciales. Al terminar sabrás decidir, con criterio y no por fe, si FOSSBilling es la herramienta correcta para tu caso, y cuál es la versión mínima que puedes desplegar sin exponerte.
La versión de referencia de todo el curso es FOSSBilling 0.8.5, publicada el 2026-07-20T02:10:43Z. Si un dato de aquí depende de la versión, está marcado como tal, con la manera de comprobarlo en tu propia instalación.
Qué es FOSSBilling y qué problema resuelve
La definición oficial está en el README.md del repositorio, verbatim:
FOSSBilling is a free, open-source billing and client management system. It helps online service businesses automate invoicing, payments, and client communication. While it’s popular with web hosting providers, it also works well for software licensing, digital downloads, and subscription services.
Traducido a operaciones concretas, FOSSBilling cubre el ciclo completo entre “un visitante quiere contratar” y “el servicio está activo y cobrado”:
| Etapa | Qué hace FOSSBilling |
|---|---|
| Catálogo | Productos con precios por periodo, cuotas de alta, addons, promociones y stock |
| Carrito y checkout | Pedido, formulario específico del producto, aplicación de cupones |
| Facturación | Emisión, numeración secuencial, impuestos, PDF, recordatorios y vencimientos |
| Cobro | Pasarelas de pago, transacciones, IPN, saldo de cliente, notas de crédito |
| Aprovisionamiento | Creación de la cuenta en el panel de hosting o registro del dominio |
| Ciclo de vida | Renovación, suspensión por impago, cancelación, reactivación |
| Relación con el cliente | Área de cliente, tickets de soporte, emails transaccionales |
El motor de todo eso es un cron.php que corre cada cinco minutos y una aplicación PHP con dos frentes: el área de administración y el área de cliente. No hay procesos residentes ni colas externas: el reloj del sistema dispara el trabajo de fondo. Ese detalle condiciona toda la operación y lo verás en detalle en el capítulo 3.
La arquitectura de alto nivel, con los tres puntos de entrada que tiene la aplicación:
flowchart TD
REQ["Peticion HTTP del navegador"] --> RW[".htaccess de Apache o rewrite de nginx"]
RW --> IDX["index.php"]
IDX --> LOAD["load.php - constantes y bootstrap"]
LOAD --> DI["di.php - contenedor Pimple"]
DI --> KERNEL["Symfony HttpKernel - routing desde 0.8.0"]
KERNEL --> MODS["modules - Controller mas Api mas Service"]
MODS --> ORM{"Capa de datos"}
ORM -->|legado| RB["RedBeanPHP"]
ORM -->|moderno| DOC["Doctrine ORM en di em"]
RB --> DB[("MySQL 8.4 o MariaDB 11.4")]
DOC --> DB
MODS --> TW["Twig - entornos admin client email"]
TW --> TH["themes - admin_default y huraga"]
TH --> RESP["Respuesta HTML"]
CRON["cron.php cada 5 minutos"] --> DI
CLI["console.php - Symfony Console"] --> DI
IPN["ipn.php - notificaciones de pasarela"] --> DILas tres entradas paralelas importan: index.php sirve al navegador, cron.php ejecuta el trabajo programado y console.php te da la CLI. ipn.php es el endpoint que las pasarelas llaman para confirmar pagos, y es la puerta por la que entró una de las vulnerabilidades críticas de 2026. Volveremos a él en el capítulo 10.
El stack real, leído del AGENTS.md del repositorio: PHP 8.3 como mínimo, componentes de Symfony —Console, Cache, Filesystem, HttpClient, HttpFoundation, HttpKernel, RateLimiter—, Twig como motor de plantillas, RedBeanPHP como ORM heredado y Doctrine DBAL/ORM como ORM moderno al que el proyecto está migrando módulo a módulo, Monolog para logs, dompdf para los PDF de factura y Pimple como contenedor de inyección de dependencias. En el frontend, Tabler.io sobre Bootstrap 5 y JavaScript vanilla: jQuery se eliminó en 0.8.0.
Los 40 módulos del core: qué trae de fábrica y qué no
Listando src/modules/ en el tag 0.8.5 salen 40 directorios:
Activity Antispam Api Branding Cart
Client Cookieconsent Cron Currency Custompages
Email Embed Extension Formbuilder Hook
Index Invoice Massmailer News Notification
Order Orderbutton Page Product Profile
Redirect Security Seo Serviceapikey Servicecustom
Servicedomain Servicedownloadable Servicehosting Servicelicense
Staff Stats Support System Theme
WidgetsSe dividen en dos categorías, y la distinción es normativa, no estética:
Uno. Service Modules. Representan productos vendibles y su nombre debe empezar por Service: Servicehosting, Servicedomain, Servicelicense, Servicedownloadable, Serviceapikey y Servicecustom. Cuando creas un producto de tipo hosting, FOSSBilling busca el módulo Servicehosting; si no está registrado, la API responde Product type :type is not registered.
Dos. Extension Modules. Todo lo demás: Invoice, Order, Client, Support, Cron, Currency, y así.
Lo que trae de fábrica en cuanto a integraciones es mucho más corto de lo que la lista de módulos sugiere. Contando ficheros en las carpetas de adaptadores:
| Familia | Ruta en el código | Contenido del core 0.8.5 |
|---|---|---|
| Pasarelas de pago | src/library/Payment/Adapter/ | ClientBalance.php, Custom.php, PayPalEmail.php, Stripe.php |
| Server managers | src/library/Server/Manager/ | CWP.php, Custom.php, Directadmin.php, Hestia.php, Plesk.php, Whm.php |
| Registradores de dominio | src/library/Registrar/Adapter/ | Custom.php, Email.php, Internetbs.php, Namecheap.php, Netearthone.php, Resellbiz.php, Resellerclub.php, Resellerid.php |
| Temas | src/themes/ | admin_default para el backend y huraga para el área de cliente |
Cuatro pasarelas de pago. No hay Mollie, ni Adyen, ni Redsys, ni Webpay, ni MercadoPago en el core. El repositorio FOSSBilling/Mollie existe pero está archivado. Si tu mercado exige una pasarela local, la respuesta honesta es: tendrás que escribir el adaptador. Es perfectamente factible —lo harás en el capítulo 10— pero es trabajo tuyo, no una casilla que marcas.
Seis server managers, ninguno de ellos Pterodactyl ni Proxmox. El repositorio FOSSBilling/Proxmox está archivado bajo GPL-3.0. Escribir el tuyo es el contenido del capítulo 11.
Y lo que no existe en el core, verificado por búsqueda en el árbol completo del tag 0.8.5:
- No hay MFA ni 2FA. Cero coincidencias para
2fa,twofactor,two_factor,totpyotpen las 1.598 rutas del release. El issue #62 «Multi-factor Authentication» sigue abierto en el milestone0.9.x, y el PR #2159 «Add Support for 2FA for “Admin”» está cerrado sin fusionar. En un sistema que administra el dinero de tus clientes, esto es una carencia grave y no tiene solución dentro de la aplicación: la mitigación es de infraestructura, y la verás en el capítulo 16. - No hay módulo de afiliados.
grep -ril "affiliate" src/devuelve cero coincidencias. Hay artículos de blog de 2026 que afirman lo contrario; son falsos para el core 0.8.5. La tablaclient_orderconserva una columna huérfanareferred_byque ningún código lee. - No hay prorrateo. Buscar
proraten todosrc/da cero resultados. Los upgrades de plan son un flujo semi-manual vía ticket de soporte. - No hay módulo de backup ni de restauración. El respaldo es responsabilidad tuya.
El fork: de BoxBilling (2022) a FOSSBilling, y por qué
FOSSBilling no nació de cero. Es un fork de BoxBilling, un sistema de billing propiedad de Boxbilling, Inc. cuyo repositorio se creó en enero de 2012.
La cronología, toda verificada contra la API de GitHub:
| Fecha | Hecho |
|---|---|
| 2012-01-23 | Se crea el repositorio boxbilling/boxbilling |
| 2020 | El LICENSE de BoxBilling declara “Copyright 2020 Boxbilling, Inc” |
| 2022-04-03 | 4.22.1.5: último release de BoxBilling |
| 2022-05-18 | Se crea el repositorio FOSSBilling/FOSSBilling |
| 2022-10-30 | El README de BoxBilling declara el proyecto sin mantenimiento y apunta a FOSSBilling |
| 2023-11-27 | Último commit en boxbilling/boxbilling |
| 2024-02-26 | Último push de BoxBilling |
| Hoy | boxbilling/boxbilling está ARCHIVADO en GitHub |
Entre el último release de BoxBilling y el nacimiento de FOSSBilling pasan seis semanas. No fue un abandono lento seguido de un rescate tardío: fue una sucesión inmediata.
El propio README archivado de BoxBilling lo confirma, verbatim:
As of the time of writing (10-30-22), BoxBilling is no longer being actively maintained.
Y sobre su estado técnico, también verbatim: “its current state has multiple bugs and vulnerabilities”. El texto dirige explícitamente a FOSSBilling como “a fork of it that is being actively developed”.
La motivación declarada por el equipo fue triple: que el proyecto estuviera bien mantenido, que no se comercializara y que la gobernanza fuera abierta en lugar de estar controlada por una empresa. La cita textual circula en material histórico de la comunidad y la FAQ oficial actual ya no la contiene, así que trátala como contexto y no como fuente primaria. El hecho del fork, en cambio, sí está verificado de forma primaria por el fichero LICENSE con doble atribución y por el README archivado de BoxBilling.
El punto que conviene entender: el fork no fue un cambio legal, fue un cambio de gobernanza. BoxBilling ya era Apache-2.0, así que forkear siempre estuvo permitido. Lo que faltaba era decidir quién mandaba.
timeline
title De BoxBilling a FOSSBilling
2012-01 : Se crea el repositorio boxbilling
2020 : LICENSE Apache-2.0 con copyright de Boxbilling Inc
2022-04 : Ultimo release de BoxBilling 4.22.1.5
2022-05 : Nace el repositorio FOSSBilling el 18 de mayo
2022-10 : BoxBilling declara el fin del mantenimiento
2023-11 : Ultimo commit en BoxBilling
2024 : BoxBilling queda archivado en GitHub
2026-05 : FOSSBilling 0.8.0 con PHP 8.3 y Symfony HttpKernel
2026-07 : FOSSBilling 0.8.5 baseline de seguridad recomendadoRastros vivos del fork en el código de 0.8.5
Cuatro años después, el linaje sigue visible. Esto no es anécdota: son cosas con las que te vas a topar programando y operando.
Uno. El namespace PHP de los módulos sigue siendo Box\Mod\. Al empaquetar el release, el Dockerfile reescribe el composer.json con esta línea:
$composer["autoload"]["psr-4"]["Box\\Mod\\"] = "modules/";
$composer["autoload"]["classmap"] = ["library/"];
$composer["config"]["vendor-dir"] = "vendor";Y console.php resuelve los comandos de módulo así:
$class = "Box\\Mod\\{$cap}\\Commands\\{$command}";Cuando escribas tu propio módulo en el capítulo 13, tus clases irán bajo Box\Mod\TuModulo\. No es un error de la documentación: es el namespace real.
Dos. Existe src/library/Box/, descrito en la documentación oficial como “Legacy compatibility classes”. Ahí vive, por ejemplo, src/library/Box/Period.php, la clase que define los periodos de facturación que usa todo el catálogo.
Tres. El .htaccess incluye reglas de compatibilidad IPN con BoxBilling, con este comentario verbatim en el fichero:
# Map legacy IPN query parameters to new query parameters, and alias
# from bb-ipn.php to ipn.php for users upgrading from BoxBilling.
# Required for older PayPal transactions as IPN cannot be updated.Las reglas traducen bb_invoice_id a invoice_id, bb_gateway_id a gateway_id, bb_redirect a redirect y bb_invoice_hash a invoice_hash, y terminan con:
RewriteRule ^bb-ipn\.php$ /ipn.php [L]Advertencia: la plantilla oficial de nginx no incluye ninguna traducción de estas reglas. Si migras desde BoxBilling y sirves con nginx, las notificaciones IPN antiguas de PayPal se pierden en silencio. Lo tratamos en el capítulo 2.
Cuatro. El proyecto lo reconoce oficialmente. El issue #1679 «Rename items that still reference BoxBilling» sigue abierto en el milestone 1.0.x. La desboxbillinguización no ha terminado, y el propio equipo lo tiene apuntado como bloqueante del 1.0.
El prefijo bb_ de los parámetros IPN se eliminó en 0.6.21, publicada el 2024-06-18. Es la razón por la que las reglas de compatibilidad existen: hay transacciones de PayPal antiguas cuyo callback no se puede reconfigurar.
Licencia Apache-2.0 y el error de leer el AGPL del sitio web
La licencia del core es Apache License 2.0, SPDX Apache-2.0. Verificado por tres vías independientes: la API de GitHub devuelve "spdx_id": "Apache-2.0", el fichero LICENSE de la raíz lo dice, y cada fichero PHP lleva la cabecera SPDX:
/**
* Copyright 2022-2025 FOSSBilling
* SPDX-License-Identifier: Apache-2.0.
*
* @copyright FOSSBilling (https://www.fossbilling.org)
* @license http://www.apache.org/licenses/LICENSE-2.0 Apache-2.0
*/El LICENSE de FOSSBilling tiene doble atribución de copyright, y ese detalle es la prueba documental del fork:
Copyright 2022 FOSSBilling
Copyright 2011-2021 Boxbilling, IncLa segunda línea es el cumplimiento visible de la cláusula de atribución de Apache-2.0 sobre el código heredado.
El error clásico
El pie de página de fossbilling.org dice AGPL 3.0. Muchísima gente —y todos los resumidores automáticos— concluye que la aplicación es AGPL. No lo es. El AGPL-3.0 cubre el sitio web y la documentación, no el software que vas a desplegar.
Licencias reales por repositorio de la organización, verificadas vía API de GitHub:
| Repositorio | Licencia | Notas |
|---|---|---|
FOSSBilling — la aplicación | Apache-2.0 | 1.667 stars, PHP |
fossbilling.org — sitio web | AGPL-3.0 | Astro |
docs — documentación | AGPL-3.0 | Astro Starlight |
api — worker de Cloudflare | AGPL-3.0 | TypeScript sobre Hono |
extensions — directorio | AGPL-3.0 | TypeScript |
locale — traducciones | Apache-2.0 | |
example-module | Apache-2.0 | Plantilla de módulo |
Demo | Apache-2.0 | Extensión para instancias demo |
config-generator | Apache-2.0 | Generador de config de servidor web |
Proxmox | GPL-3.0 | ARCHIVADO |
Mollie | Apache-2.0 | ARCHIVADO |
branding | sin licencia declarada | Logos |
graph LR
ORG["Organizacion FOSSBilling"] --> APP["FOSSBilling - la aplicacion<br/>Apache-2.0"]
ORG --> WEB["fossbilling.org - sitio web<br/>AGPL-3.0"]
ORG --> DOCS["docs - documentacion<br/>AGPL-3.0"]
ORG --> API["api - worker Cloudflare<br/>AGPL-3.0"]
ORG --> EXT["extensions - directorio<br/>AGPL-3.0"]
ORG --> LOC["locale - traducciones<br/>Apache-2.0"]
ORG --> EXM["example-module<br/>Apache-2.0"]
ORG --> PVE["Proxmox - ARCHIVADO<br/>GPL-3.0"]
ORG --> MOL["Mollie - ARCHIVADO<br/>Apache-2.0"]
APP --> USO["Uso comercial sin publicar tus cambios"]
WEB --> COPY["El AGPL del pie de pagina es de aqui"]Implicación práctica si montas un negocio con esto: Apache-2.0 te permite usar FOSSBilling comercialmente, modificarlo y no publicar tus modificaciones, ni siquiera ofreciéndolo como servicio en red —que es justo lo que AGPL sí obligaría—. Solo debes conservar los avisos de copyright y de licencia e indicar los cambios significativos. Apache-2.0 además incluye una concesión expresa de patentes en su sección 3, que ni GPL-2.0 ni MIT ofrecen explícitamente.
Estado real: beta declarada en tres sitios oficiales
Esto no es una opinión de terceros. El propio proyecto lo declara en tres lugares distintos.
Uno. El README del repositorio, en un aviso destacado, verbatim:
FOSSBilling is under active development and currently considered beta. Expect rough edges and limited support.
Dos. La página de descargas de fossbilling.org/downloads/, verbatim:
FOSSBilling is currently pre-production software
Con tres prerrequisitos declarados en la misma página: leer las release notes antes de actualizar, tener conocimiento técnico de PHP y hosting web, e instalar en un subdominio o dominio de primer nivel, nunca en subcarpeta.
Tres. La FAQ oficial en docs.fossbilling.org/support/faq/, verbatim:
FOSSBilling is actively developed and still moving toward a 1.0 release. It is already usable, but you should treat production deployments with the same care you would apply to any billing system: keep backups, test updates in staging, and avoid running unreleased code unless you understand the risk.
El matiz importa: el tono de la FAQ es notablemente más suave que el “beta” del README. “It is already usable” es una afirmación positiva. La postura oficial de 2026 se resume así: usable en producción, con la disciplina operativa que exigirías a cualquier sistema que maneja dinero.
Hay un tercer indicio, este en el propio código. src/library/FOSSBilling/Version.php distingue versiones preview:
public static function isPreviewVersion(string $version = Version::VERSION): bool
{
return ($version !== '0.0.1' && preg_match(self::semverRegex, $version, $matches) !== 0) ? false : true;
}En el repositorio la constante VERSION vale '0.0.1', un placeholder. El número real se inyecta durante el build del release, sustituyendo esa línea. Por eso los builds de preview, que llevan el SHA del commit truncado a siete caracteres como versión, dan true en isPreviewVersion(): un SHA no matchea el regex de SemVer.
¿Cuándo llega el 1.0? El milestone 1.0.x tiene 34 issues abiertos y due_on es null —sin fecha comprometida— igual que en todos los demás milestones. Entre esos 34 hay tres que por sí solos indican que no está cerca:
#52Rewrite the whole tax system — reescritura completa del sistema de impuestos.#556Rewrite the cart module — reescritura completa del carrito.#1678Legal review prior to release of v1.0 — revisión legal pendiente.
Y otros de peso: #983 instalar y actualizar extensiones desde el panel, #589 que la API deje de devolver siempre 200, #2968 pro-rata billing, #3816 API keys con scope, #432 tareas en segundo plano.
Cadencia de releases: los huecos de 2024-2025 y la aceleración de 2026
El historial reciente, verificado en la API de GitHub:
| Versión | Fecha | Titular |
|---|---|---|
| 0.8.5 | 2026-07-20 | Seguridad de sesiones, cancelación a fin de periodo, email de facturación separado, fixes de Stripe |
| 0.8.4 | 2026-07-11 | Stripe con suscripciones recurrentes; permisos de admin pasan de por-usuario a por grupo |
| 0.8.3 | 2026-06-20 | Tickets públicos unificados con los de cliente; toggle claro/oscuro en admin |
| 0.8.2 | 2026-06-04 | Rate limiting en APIs guest de factura, PDF y pago; caducidad del hash de factura |
| 0.8.1 | 2026-05-30 | Subdominios gratuitos para hosting; reCAPTCHA v3; actualización en dos fases |
| 0.8.0 | 2026-05-28 | Release mayor. PHP 8.3+, guest API refactorizada, módulo Antispam, Widgets |
| 0.7.2 | 2025-09-07 | Fix de autenticación de facturas en cronjobs |
| 0.7.1 | 2025-07-02 | Fix de cabeceras de reverse proxy |
| 0.7.0 | 2025-06-28 | PHP 8.4, elimina PHP 8.1, nueva CLI |
| 0.6.22 | 2024-06-21 | Fix de PayPal |
Hay un hueco de unos nueve meses entre 0.6.22 y 0.7.0, y otro de ocho entre 0.7.2 y 0.8.0. Si evaluaste FOSSBilling en 2025 y lo descartaste por parecer parado, la foto de hoy es distinta: seis releases en menos de dos meses entre mayo y julio de 2026.
Las métricas del repositorio confirman la aceleración:
| Métrica | Valor |
|---|---|
| Stars | 1.667 |
| Forks | 342 |
| Issues abiertos | 177 |
| Contribuidores | 108 |
| Commits por semana en 2026 | entre 36 y 92 |
| Commits por semana hace 12 meses | entre 8 y 21 |
| Total de releases publicados | 57 |
| Rama por defecto | main |
Un multiplicador de tres a cuatro veces respecto a hace un año. No es un proyecto en decadencia: es un proyecto en aceleración.
Puedes comprobar la versión vigente ahora mismo sin depender de este texto. La API oficial del proyecto es la misma fuente que consultan las propias instancias para detectar actualizaciones:
curl -sS https://api.fossbilling.org/versions/latest{
"version": "0.8.5",
"released_on": "2026-07-20T02:10:43Z",
"minimum_php_version": "8.3",
"download_url": "https://github.com/FOSSBilling/FOSSBilling/releases/download/0.8.5/FOSSBilling-0.8.5.zip",
"size_bytes": 31069155,
"is_prerelease": false,
"github_release_id": 352974509
}Dos campos que usarás de verdad: minimum_php_version te dice el PHP mínimo del release, y download_url es la única URL de descarga fiable —el atajo fossbilling.org/downloads/stable está roto y devuelve 404, cosa que verás con detalle en el capítulo 2—. El endpoint /versions/count devuelve el total de releases.
Y para saber qué versión corre una instalación concreta, la propia guía de contribución da la ruta:
curl -sS https://tu-dominio.example/api/guest/system/versionLos 32 advisories de 2026 y las cuatro vulnerabilidades críticas
Este es el dato que más pesa en la decisión, y el que más se omite en las reseñas entusiastas.
FOSSBilling ha publicado 32 advisories de seguridad, y los 32 son de 2026. Distribución por severidad:
| Severidad | Cantidad |
|---|---|
| Critical | 4 |
| High | 12 |
| Medium | 11 |
| Low | 5 |
| Total | 32 |
Ningún advisory publicado antes de 2026. Los cuatro críticos, todos corregidos en 0.8.0:
| CVE | Publicado | Qué permite | Rango vulnerable |
|---|---|---|---|
CVE-2026-33543 | 2026-06-20 | Authentication bypass: creación de un administrador sin autenticarse | <= 0.7.2 |
CVE-2026-28496 | 2026-06-20 | SSTI en el renderizado Twig, con divulgación de información | <= 0.7.2 |
CVE-2026-27604 | 2026-06-20 | Improper API role validation: acceso no autenticado a endpoints privilegiados | >= 0.5.4, < 0.8.0 |
CVE-2026-42341 | 2026-06-20 | Payment bypass mediante forja del callback IPN | >= 0.6.0, <= 0.7.2 |
Léelo despacio: crear un administrador sin credenciales, ejecutar plantillas arbitrarias y dar por pagada una factura que nadie pagó. En un sistema de facturación, los tres primeros premios.
Los HIGH posteriores a 0.8.0 son los que justifican no quedarse en 0.8.0 y llegar hasta 0.8.5:
| CVE | Publicado | Qué permite | Parcheado en |
|---|---|---|---|
CVE-2026-62962 | 2026-07-28 | Autorización faltante en endpoints de configuración de extensiones | 0.8.4 |
CVE-2026-68542 | 2026-07-20 | El adaptador IPN de PayPalEmail no verifica el destinatario: forja de pagos | 0.8.4 |
CVE-2026-68543 | 2026-07-20 | Precio de pedido no validado al crear desde admin: aprovisionamiento sin pago | 0.8.4 |
CVE-2026-68544 | 2026-07-28 | El reset de contraseña no revoca las sesiones existentes | 0.8.5 |
CVE-2026-68545 | 2026-07-28 | Pedidos de hosting expirados siguen gestionables vía client API hasta la suspensión por cron | 0.8.5 |
CVE-2026-53648 | 2026-06-12 | Ficheros de productos descargables sobrescribibles por colisión de nombre | 0.8.1 |
Otros HIGH corregidos en 0.8.0, todos con rango <= 0.7.2: CVE-2026-43921 —inyección de código PHP arbitrario por serialización de configuración sin escapar—, CVE-2026-53646 —reutilización del token de reset de contraseña, con account takeover persistente—, CVE-2026-43918 —las cuentas suspendidas conservan acceso a través de sesiones vivas—, CVE-2026-27708 —IDOR en Servicecustom—, más CVE-2026-23513, CVE-2026-53643, CVE-2026-53645 y CVE-2026-42331.
Cómo interpretar esto sin engañarte
Hay dos lecturas y las dos son válidas. Quédate con las dos, no con una.
La lectura pesimista: 32 CVEs en un solo año, cuatro críticos, en software que maneja dinero y datos personales de tus clientes. Toda la base instalada anterior a 0.8.0 es comprometible con exploits públicos y documentados.
La lectura optimista: que existan 32 advisories bien redactados, con CVE asignado, rango de versiones preciso y versión parcheada, indica un proyecto que auditó su propio código heredado y publicó los resultados. La ausencia total de advisories antes de 2026 no significa que no hubiera vulnerabilidades: significa que nadie las estaba buscando ni publicando. El código heredado de BoxBilling, sin mantenimiento desde 2022, arrastraba estos fallos. Sacarlos a la luz es un acto de madurez, no de fracaso.
La política de reporte está en .github/SECURITY.md: los reportes se abren directamente como advisory privado en GitHub, no como issue público. No hay bug bounty económico; el reconocimiento es crédito en el advisory. Se rechazan explícitamente los reportes de escáneres automáticos, los ataques teóricos sin prueba de explotabilidad y todo lo que esté en /tests. Y hay una nota sobre IA que vale la pena citar verbatim:
If you are unable to perform security research / development without the assistance of an AI, then please do not attempt to do so for the FOSSBilling project.
La alerta central no descartable y la regla de versión mínima
FOSSBilling tiene un mecanismo llamado Central Alerts: cada instancia consulta una API del proyecto y muestra los avisos en el panel de administración. El contenido actual:
curl -sS https://fossbilling.org/api/central-alerts/list{
"id": "1",
"title": "This version of FOSSBilling is insecure",
"message": "FOSSBilling versions older than v0.8.0 contain critical security vulnerabilities that allow attackers to take direct control of your server. Update now to protect your business and your customers.",
"type": "danger",
"dismissible": false,
"min_fossbilling_version": "0.0.0",
"max_fossbilling_version": "0.7.2",
"include_preview_branch": false,
"buttons": [
{"text": "Migration guide", "link": "https://docs.fossbilling.org/maintenance/updating/0-7-to-0-8/", "type": "info"},
{"text": "Discord server", "link": "https://fossbilling.org/discord/", "type": "info"}
],
"datetime": "2026-06-02T20:51:59+00:00"
}Fíjate en dos campos. "type": "danger" y, sobre todo, "dismissible": false: el propio proyecto considera esto tan grave que no te deja cerrar el aviso. El rango max_fossbilling_version: "0.7.2" significa que cualquier instalación en 0.7.2 o inferior lo verá permanentemente en su panel.
El changelog de 0.8.5 cierra el argumento, verbatim:
Alongside this release, we are publishing several security advisories for vulnerabilities addressed in 0.8.4 and later. Users should upgrade as soon as possible as prior releases contain critical vulnerabilities. 0.8.5 should be considered the recommended security baseline.
La regla operativa de este curso, sin matices:
- Instala 0.8.5 o superior. Nada más bajo.
- Nunca 0.7.x ni anteriores, ni siquiera para “probar” en un servidor accesible desde internet.
- Nunca BoxBilling. Está archivado, sin parches desde 2022 y su propio README avisa de “multiple bugs and vulnerabilities”.
- Si heredas una instalación existente, lo primero es
curl https://esa-instancia/api/guest/system/versiony, si el número empieza por 0.7 o menos, tratarla como comprometida hasta demostrar lo contrario.
Un detalle de privacidad que conviene saber: toda instalación de FOSSBilling consulta api.fossbilling.org para comprobar versión y alertas centrales. Antes de 0.6.20 se consultaba directamente la API de GitHub. No hay telemetría más allá de eso —el issue #38 Opt-In Telemetry sigue abierto en el milestone 1.0.x— pero el tráfico saliente existe y es intencional.
Gobernanza: comité de cinco, 108 contribuidores, 791 dólares al año
Leyendo GOVERNANCE.md: no existe ninguna fundación, organización legal ni empresa detrás de FOSSBilling. Es un proyecto comunitario bajo Apache-2.0 con un comité de dirección. Contraste directo con BoxBilling, que era propiedad de Boxbilling, Inc.
La estructura tiene tres niveles:
flowchart TD
CM["Community Members<br/>Cualquiera que use o contribuya<br/>Sin barrera de entrada"]
MA["Maintainers<br/>Revisan codigo y triagean issues<br/>Un mes de periodo provisional"]
SC["Steering Committee<br/>5 contribuidores activos<br/>Acceso administrativo a la organizacion"]
PROY["Salud y direccion a largo plazo del proyecto"]
CM -->|nominacion por maintainers o por el comite| MA
MA --> SC
SC --> PROYSteering Committee actual, con los nombres verbatim del documento: admdly, BelleNottelling, yagiz-dev, HunterNyan, jaapmarcus. Cinco personas.
La toma de decisiones funciona por Lazy Consensus, verbatim del documento:
If a proposal is made and no objections are raised within a reasonable timeframe (typically 5-7 days), it is considered accepted.
Para asuntos significativos hay un proceso formal: propuesta pública, discusión, voto del comité por mayoría simple y decisión final del comité. Solo las enmiendas a la propia gobernanza requieren voto de toda la comunidad por mayoría de dos tercios.
El presupuesto
Este es el número que pone las cosas en perspectiva. Datos verificados en opencollective.com/fossbilling.json:
| Métrica | Valor |
|---|---|
| Balance actual | 1.955,11 USD |
| Ingreso anual | 791,00 USD |
| Backers | 33 |
791 dólares al año. Con 108 contribuidores, el trabajo es esencialmente no remunerado. La política declarada en la FAQ es que los fondos de GitHub Sponsors se transfieren a Open Collective para centralizar y hacer públicas las cuentas, y que el dinero cubre herramientas, servicios e infraestructura, con la mayoría del hosting donado.
Esto es un riesgo real de sostenibilidad —bus factor de cinco personas— y hay que decirlo. También explica por qué comparar FOSSBilling con WHMCS no es una comparación simétrica: al otro lado hay una empresa, WebPros, con ingresos de millones.
Comparativa honesta con WHMCS, Blesta, HostBill y BoxBilling
| FOSSBilling | WHMCS | Blesta | HostBill | BoxBilling | |
|---|---|---|---|---|---|
| Licencia | Apache-2.0, OSI open source | Propietaria, código ionCube | Comercial source-available | Propietaria | Apache-2.0, archivado |
| Coste | 0 USD | 34,95 a 84,95 USD/mes self-hosted | 17,95 a 23,95 USD/mes o 350 a 1.495 USD perpetua | 599 a 5.999 USD perpetua | 0 USD |
| Modelo de licencia | Sin límite | Por clientes activos | Por licencia branded, unbranded o flex | Perpetua por edición | Sin límite |
| Marca removible | Sí siempre | n/a | Solo en Unbranded | Sí en todas | Sí |
| Empresa detrás | Ninguna, comité comunitario | WebPros | Phillips Data, Inc. | HostBill | Boxbilling, Inc. difunta |
| Estado | Beta, 0.8.5 | Maduro | Maduro | Maduro | Muerto desde 2022-04 |
| Integraciones | 4 pasarelas, 6 server managers, 8 registradores | Cientos | Amplio | 106+ integraciones, 162+ apps | Congelado |
| Puedes leer el código | Sí, todo | No | Casi todo | No | Sí |
| Puedes redistribuir | Sí | No | No | No | Sí |
| MFA/2FA | No | Sí | Sí | Sí | No |
Precios verificados a agosto de 2026
WHMCS self-hosted, escalando por número de clientes activos:
| Plan | Clientes activos | Precio |
|---|---|---|
| Plus | hasta 250 | 34,95 USD/mes |
| Professional | hasta 500 | 54,95 USD/mes |
| Business | hasta 1.000 | 84,95 USD/mes |
Blesta, licencia mensual: Branded 17,95 USD, Unbranded 20,95 USD, Flex 23,95 USD. Licencia perpetua: Branded 350 USD, Unbranded 425 USD, Flex 500 USD, Lifetime 1.295 USD, Lifetime Flex 1.495 USD. Renovación opcional de soporte tras el primer año: 62 USD/año.
HostBill, licencias perpetuas de pago único: Startup 599 USD con 10 casos de soporte, Enterprise 999 USD, Data Center 1.599 USD y All-Inclusive 5.999 USD con las 106+ integraciones. Renovación de actualizaciones 125 USD/año.
El matiz de Blesta que su marketing difumina
Blesta se anuncia como “self-hosted, open, endlessly extensible” y casi todo su código es legible. Pero no es open source. Es source-available: licencia comercial, todos los ficheros PHP legibles excepto seis —tres cifrados para la protección de licencia y tres para su función de IA— y sin derecho de redistribución ni de fork. Si “open” para ti significa “puedo forkearlo si el proveedor cambia de rumbo”, Blesta no cumple y FOSSBilling sí.
BoxBilling merece una frase y solo una: gratis, Apache-2.0 y completamente inutilizable. Repositorio archivado, último release 2022-04-03, último commit 2023-11-27, y su propio README advirtiendo de bugs y vulnerabilidades. No lo despliegues en 2026 bajo ninguna circunstancia.
Una nota sobre Jelastic, que aparece en muchas comparativas: Jelastic —hoy Virtuozzo Application Platform— no es un competidor directo. Es un PaaS con facturación integrada para su propio modelo de recursos, no un sistema de billing genérico que apuntes a cPanel o a un registrador. Si buscas una cuarta alternativa comercial comparable, los candidatos correctos son Clientexec, WISECP y Ubersmith, pero ninguno de los tres se investigó para este curso, así que no encontrarás datos de ellos aquí.
Qué ganas y qué pierdes al elegir FOSSBilling
Lo que ganas
Uno. Coste cero sin techo de clientes. WHMCS cobra por cliente activo: a 1.000 clientes son 84,95 USD/mes, es decir 1.019 USD al año recurrentes, indefinidamente. FOSSBilling cuesta lo mismo con 10 que con 10.000 clientes. En cinco años la diferencia con WHMCS Business ronda los 5.100 USD.
Dos. Control total del código. Con Apache-2.0 puedes leerlo, auditarlo, parchearlo el mismo día que descubras un fallo y desplegar tu versión parcheada. Con WHMCS y su código ionCube ni siquiera puedes leer la rutina que procesa los pagos de tus clientes.
Tres. Sin vendor lock-in ni riesgo de cambio de precios. Una empresa puede subir tarifas, discontinuar tu plan o ser adquirida. Un release Apache-2.0 que ya descargaste no te lo puede quitar nadie.
Cuatro. Sin activación de licencia. No hay callback a un servidor de licencias que pueda caer, caducar o bloquearte. Relevante en entornos air-gapped o de alta disponibilidad.
Cinco. Concesión expresa de patentes, sección 3 de Apache-2.0.
Seis. Auditabilidad total. Los 32 advisories de 2026 existen precisamente porque el código es auditable. Es la contrapartida positiva del dato incómodo.
Siete. Extensibilidad documentada. Hay guías oficiales para crear módulos, pasarelas, registradores, server managers y temas, y las recorrerás en los capítulos 10 a 15.
Lo que pierdes
Uno. Estado beta, sin 1.0. 34 issues bloqueando el milestone, incluidas dos reescrituras completas y una revisión legal.
Dos. Ecosistema de integraciones minúsculo. Cuatro pasarelas frente a cientos. Si necesitas una pasarela o un panel concreto, es probable que tengas que escribirlo.
Tres. Sin MFA ni 2FA. Issue #62 abierto, PR #2159 cerrado sin fusionar. Sin solución en la aplicación.
Cuatro. Sin soporte comercial. El README dice “limited support”. Solo Discord comunitario.
Cinco. Funcionalidades que darías por sentadas y no están: impuestos avanzados —a reescribir en #52—, pro-rata billing, backups y exportaciones, restauración e importaciones, adjuntos en tickets, adjuntos en email, sistema de referidos, precios por uso, actualizaciones automáticas, email-to-ticket —FOSSBilling no lee buzones—, zona horaria por cliente y una sola dirección de correo saliente.
Seis. Historial de seguridad de 2026 pesado. 32 CVEs, cuatro críticos.
Siete. Presupuesto de 791 USD/año y cinco personas al mando. Bus factor real.
Ocho. No soporta instalación en subcarpeta. Exige dominio o subdominio dedicado, deprecado desde 0.4.2.
Nueve. Sin integración con Pterodactyl, y el core declara que no planea construirla. Relevante si vendes hosting de servidores de juego.
Árbol de decisión: cuándo sí y cuándo no
flowchart TD
A["Necesito un sistema de billing<br/>para hosting o servicios"] --> B{"Toleras estado beta<br/>y parchear tu mismo?"}
B -->|No| C{"Que presupuesto<br/>puedes asumir?"}
B -->|Si| D{"Necesitas MFA<br/>obligatorio hoy?"}
C -->|Mensual recurrente| E["WHMCS<br/>ecosistema mayor"]
C -->|Pago unico| F["HostBill desde 599 USD<br/>o Blesta perpetua desde 350 USD"]
D -->|Si| G["Espera al milestone 0.9.x<br/>o usa una alternativa"]
D -->|No| H{"Necesitas una pasarela<br/>o un panel exotico?"}
H -->|Si| I{"Puedes escribir<br/>el adaptador tu mismo?"}
H -->|No| J["FOSSBilling 0.8.5"]
I -->|Si puedo| J
I -->|No puedo| ETraducido a criterios operativos:
FOSSBilling encaja si vendes hosting compartido con cPanel, DirectAdmin, Plesk, Hestia o CWP; cobras con Stripe, PayPal o transferencia manual; tienes o puedes contratar a alguien que lea PHP; puedes probar cada actualización en staging antes de aplicarla en producción; y el número de clientes hace que la factura de WHMCS te duela.
FOSSBilling no encaja si necesitas MFA obligatorio por política o por cumplimiento; dependes de una pasarela local sin adaptador y nadie va a escribirlo; necesitas prorrateo real en upgrades; tu contabilidad exige un sistema de impuestos complejo que hoy está pendiente de reescritura; o no tienes a nadie que pueda parchear a mano si aparece un CVE crítico un viernes por la noche.
Un punto intermedio razonable: monta la instalación del capítulo 2 en un VPS de pruebas, carga tu catálogo real del capítulo 5 y emite una factura de verdad siguiendo el capítulo 8. Con eso sabrás en un rato si el modelo de datos aguanta tu negocio, mucho mejor que con cualquier comparativa.
Comunidad, documentación oficial y recursos verificados
Discord es el canal de soporte de facto
| Dato | Valor |
|---|---|
| Shortlink oficial | https://fossbilling.org/discord |
| Redirige con 301 a | https://discord.com/invite/bVjMZSgtbY |
| Guild ID | 747432407757488179 |
| Miembros aproximados | 1.636 |
| Invitación | permanente |
Discord aparece en la FAQ, en la guía de troubleshooting, en la sección de soporte de la documentación y en los botones de la propia Central Alerts API. Es donde se responde.
El foro está caído
https://forum.fossbilling.org devolvía HTTP 525 — SSL handshake failed en la comprobación del 2026-08-10. El DNS sigue resolviendo a IPs de Cloudflare, pero el origen no responde. El foro sigue enlazado desde el README y GOVERNANCE.md lo lista como uno de los tres espacios públicos de discusión, pero la documentación actual ya no lo menciona en ninguna parte. No se pudo determinar si es una caída temporal o un decomiso definitivo. Para efectos prácticos: usa Discord y GitHub.
Demo pública
Antes de instalar nada, puedes tocar el panel real:
| Área | URL | Credenciales |
|---|---|---|
| Administración | https://demo.fossbilling.org/admin | [email protected] / Demo123! |
| Cliente | https://demo.fossbilling.org | [email protected] / Demo123! |
La instancia se resetea periódicamente, así que no guardes nada que quieras conservar.
Documentación y demás recursos
| Recurso | URL |
|---|---|
| Documentación oficial | https://docs.fossbilling.org/ |
| Repositorio de la aplicación | https://github.com/FOSSBilling/FOSSBilling |
| Advisories de seguridad | https://github.com/FOSSBilling/FOSSBilling/security/advisories |
| API de versiones | https://api.fossbilling.org/versions/latest |
| Central Alerts | https://fossbilling.org/api/central-alerts/list |
| Directorio de extensiones | https://extensions.fossbilling.org |
| Traducciones | https://translate.fossbilling.org/ |
| Open Collective | https://opencollective.com/fossbilling |
| GitHub Sponsors | https://github.com/sponsors/FOSSBilling |
| Contacto | [email protected] |
La documentación está construida con Astro Starlight y sus secciones son: Getting Started, Admin Guide, Maintenance, Security, Extensions & Development y Support. Las rutas que más vas a visitar en este curso son /getting-started/requirements/, /admin-guide/config/, /maintenance/troubleshooting/ y /security/securing-fossbilling/.
Gotcha de documentación: el comentario de cabecera de config-sample.php apunta a docs.fossbilling.org/customizing-fossbilling/config/, que es una URL muerta. La ruta real hoy es /admin-guide/config/. Es un recordatorio útil de que hasta la documentación embebida en el código puede quedarse atrás; siempre comprueba antes de copiar una URL a un script.
Cómo se reporta un bug y cómo se contribuye
Antes de abrir un issue, la guía pide buscar en los existentes. Para vulnerabilidades, nunca un issue público: se usa el formulario privado de advisories. Un reporte útil incluye pasos exactos de reproducción, comportamiento esperado frente al observado, capturas, y los datos del entorno: versión de FOSSBilling, sistema operativo, versión de PHP, versión de MySQL y servidor web.
Para contribuir código: PSR-12 en PHP, JavaScript vanilla moderno sin jQuery, primera línea del commit de 72 caracteres como máximo, en presente e imperativo, y dos reviews de maintainers obligatorias antes de fusionar. El código de conducta es Contributor Covenant v3.
Errores comunes y diagnóstico
Los fallos de este capítulo son de criterio y de versión, no de configuración —esos empiezan en el capítulo 2—. Aun así, estos son los que más caros salen:
| Síntoma o creencia | Causa | Cómo lo compruebas o lo corriges |
|---|---|---|
| ”FOSSBilling es AGPL, no puedo usarlo comercialmente sin publicar mis cambios” | Se leyó el pie de página de fossbilling.org, que es la licencia del sitio web | El fichero LICENSE de la aplicación dice Apache-2.0. La API de GitHub devuelve "spdx_id": "Apache-2.0" |
| Instalación heredada con banner rojo que no se puede cerrar | La Central Alert con dismissible: false para versiones <= 0.7.2 | curl https://tu-dominio/api/guest/system/version. Si es 0.7.x o menor, actualizar a 0.8.5 es urgente, no opcional |
| ”Instalé la última versión y sigo viendo advisories abiertos” | 0.8.0 corrige los cuatro críticos, pero CVE-2026-68544 y CVE-2026-68545 se corrigen en 0.8.5 | Comparar tu versión contra 0.8.5, no contra 0.8.0 |
| Se planificó el proyecto contando con 2FA para el staff | No existe en el core: #62 abierto, #2159 cerrado sin fusionar | Buscar totp u otp en el árbol del release da cero resultados. Mitigar por IP o VPN a nivel de servidor web |
| Se prometió al cliente un programa de afiliados | No hay módulo Affiliate en el core; grep -ril "affiliate" src/ da cero | La columna client_order.referred_by está huérfana. Issue #2565 abierto sin PR |
| Se contó con prorrateo en los cambios de plan | grep prorat src/ da cero coincidencias | El upgrade es un ticket con rel_task = upgrade que un administrador ejecuta a mano |
| Un tutorial de 2025 no coincide con lo que ves en el panel | El salto 0.7.x a 0.8.x de mayo de 2026 rediseñó el panel, monedas y permisos de staff | Descartar cualquier material anterior a 2026-05-28. En 0.8.4 los permisos pasaron de por-usuario a por grupo |
| El script de despliegue descarga y falla con 404 | https://fossbilling.org/downloads/stable apunta a FOSSBilling.zip, nombre de asset que dejó de existir en 0.8.x | Resolver download_url desde https://api.fossbilling.org/versions/latest |
| Se instaló BoxBilling porque “es lo mismo y más estable” | Está archivado desde 2024, sin parches desde 2022 | Su propio README admite “multiple bugs and vulnerabilities”. Migrar a FOSSBilling 0.8.5 |
| No se encuentran las clases del módulo propio | El namespace sigue siendo Box\Mod\, herencia del fork | Ver el psr-4 que inyecta el Dockerfile y la resolución de comandos en console.php |
| Enlaces de la documentación que dan 404 | Rutas movidas, como la de config-sample.php | La ruta viva de configuración es /admin-guide/config/ |
| El foro oficial no carga | forum.fossbilling.org devuelve HTTP 525 | Usar Discord y GitHub Issues |
Checklist antes de comprometerte con FOSSBilling
- La versión que vas a instalar es 0.8.5 o superior.
- Tu pasarela de pago está entre las cuatro del core, o tienes quien escriba el adaptador.
- Tu panel de hosting está entre los seis del core, o tienes quien escriba el server manager.
- No necesitas MFA obligatorio para el staff hoy, o puedes restringir el panel por IP o VPN.
- No dependes de prorrateo automático en upgrades.
- Tienes un plan de backup propio: la base de datos y
config.phpcon suinfo.salt. - Puedes probar cada actualización en staging antes de tocar producción.
- Alguien de tu equipo lee PHP lo bastante bien como para aplicar un parche urgente.
Si marcas las ocho, adelante. Si fallan las dos últimas, el ahorro frente a WHMCS puede salirte caro.
Lo que queda claro y qué sigue
FOSSBilling es un fork Apache-2.0 de BoxBilling nacido en mayo de 2022, con 40 módulos de core, cuatro pasarelas, seis server managers y ocho registradores de fábrica. Sigue siendo beta declarada en el README, en la página de descargas y en la FAQ; su milestone 1.0.x tiene 34 issues abiertos sin fecha; publicó 32 advisories en 2026 con cuatro críticos; y se mantiene con 108 contribuidores, un comité de cinco personas y 791 dólares al año. También aceleró de forma clara en 2026, con seis releases en dos meses y entre 36 y 92 commits semanales.
La regla que te llevas: 0.8.5 es el baseline mínimo, dicho por el propio changelog. Y la licencia que te importa es la de la aplicación, Apache-2.0, no el AGPL del sitio web.
Con la decisión tomada, el siguiente paso es ponerlo en marcha. En el capítulo 2 montas las dos rutas de instalación completas: un VPS con nginx, PHP-FPM y MariaDB, y el despliegue con Docker Compose. Incluye los requisitos reales que comprueba el código —que no coinciden con la documentación—, el enlace de descarga oficial que hoy devuelve 404 y la trampa del volumen que hace que cambiar el tag de la imagen no actualice nada.