A diferencia de wp-config.php, config.json no es un archivo estándar de WordPress. WordPress Core no crea ni utiliza un config.json.

Si encuentras un archivo como:
https://ejemplo.com/config.json o https://ejemplo.com/wp-content/config.json
lo más probable es que haya sido creado por: Un plugin, un tema, una aplicación JavaScript (React, Vue, Angular, etc.), o un desarrollador lo creo como archivo de configuración.

Proteger un archivo config.json que pueda estar expuesto es una medida de seguridad importante, ya que estos archivos suelen contener información sensible como credenciales de bases de datos o claves de API.

¿Por qué puede ser una vulnerabilidad?

El riesgo no es el archivo en sí, sino la información que contiene y si es accesible públicamente.

Un config.json mal configurado puede exponer datos como:

{ "apiKey": "...", "apiSecret": "...", "database": { "host": "...", "user": "...", "password": "..." }, "smtp": { "username": "...", "password": "..." }, "jwt_secret": "...", "license_key": "...", "debug": true }

Si un atacante puede descargar ese archivo, podría obtener credenciales o información útil para comprometer el sitio.

Riesgos más comunes

1. Exposición de claves API

Muchas aplicaciones almacenan:

  1. Claves de OpenAI
  2. Google Maps API
  3. Stripe
  4. PayPal
  5. Firebase
  6. Amazon S3

Si esas claves tienen permisos elevados, un atacante podría abusar de ellas.

2. Credenciales de bases de datos

Nunca deberían aparecer en un archivo accesible desde Internet.

3. Secretos criptográficos

Algunos desarrolladores almacenan:

  1. JWT Secret
  2. OAuth Client Secret
  3. Tokens de acceso
  4. Claves privadas

Su exposición puede permitir falsificar autenticaciones o acceder a servicios.

4. Información sobre la infraestructura

Incluso sin credenciales, un config.json puede revelar:

  1. Versiones de software.
  2. URLs internas.
  3. Nombres de servidores.
  4. Rutas de archivos.
  5. Entornos de desarrollo.

Esa información facilita ataques dirigidos.

¿Cómo saber si representa un riesgo?

No basta con comprobar que el archivo existe. Debes revisar si:

  1. Es accesible públicamente mediante HTTP.
  2. Contiene información sensible.
  3. Incluye credenciales, tokens o secretos.
  4. Expone detalles internos del servidor o la aplicación.

¿Es una vulnerabilidad de WordPress?

No.

config.json no pertenece al núcleo de WordPress, por lo que su existencia no indica una vulnerabilidad del CMS.

Sin embargo, sí puede convertirse en una vulnerabilidad de alta gravedad si está expuesto y contiene información sensible.

¿Deberías incluirlo en un escáner de seguridad?

Sí. Es recomendable que un escáner compruebe si existen archivos de configuración comunes accesibles públicamente, entre ellos:

config.json config.js appsettings.json .env .env.production settings.json firebase.json composer.json composer.lock

Si alguno de ellos es accesible, el siguiente paso debe ser analizar si expone información sensible o representa un riesgo para la seguridad del sitio.

Opciones de Protección

Para un archivo config.json de una aplicación o plugin (ej. WPEngine, Akeeba)

Si el archivo pertenece a un plugin o a tu hosting (como el archivo _wpeprivate/config.json de WPEngine o el de Akeeba Backup ), la solución es bloquear el acceso a la carpeta que lo contiene. Esto evita que cualquier persona pueda leer el archivo directamente desde el navegador.

En servidores Apache: Puedes crear un archivo .htaccess dentro de la carpeta que contiene el config.json con el siguiente código:

Require all denied

O, si prefieres protegerlo desde la raíz, puedes usar una regla específica:

<FilesMatch "config\.json$"> Require all denied </FilesMatch>

En servidores Nginx: Debes agregar una regla en la configuración del servidor para denegar el acceso a esa ruta:

location ~* /_wpeprivate/ { deny all; return 403; }

Para un archivo config.json que tu propia aplicación (ej. Angular) necesita leer

Si tu aplicación (como una hecha en Angular) necesita leer este archivo mediante una llamada HTTP, la situación es más compleja. No es posible bloquear completamente el acceso a un archivo que el navegador del usuario necesita descargar.

La limitación: Si el navegador puede hacer la petición para obtener el archivo, un usuario malintencionado puede replicar esa misma petición desde su navegador (por ejemplo, usando las herramientas de desarrollador) y leer su contenido.

Solución de "disuasión": Puedes configurar tu servidor (Apache o Nginx) para que solo sirva el archivo si la petición incluye un encabezado HTTP personalizado específico.

Esto bloquearía el acceso directo por URL, ya que un navegador no envía ese encabezado por defecto . Sin embargo, como se ha mencionado, no es una solución infalible, ya que el encabezado puede ser falsificado.

En estos casos, la verdadera solución es de diseño: no incluir información sensible en archivos JSON que se sirven al cliente.

Verifica la seguridad después de aplicar el cambio: Tras añadir el código de protección, siempre es buena práctica probarlo.

Intenta acceder al archivo config.json directamente desde tu navegador web.
Si ves un error 403 Forbidden (o similar), significa que el bloqueo ha funcionado correctamente.