apisix/batch-requests plugin allows overwriting the X-REAL-IP header

O plugin batch-requests do Apache APISIX permite que um cliente externo sobrescreva o cabeçalho X-REAL-IP usado pelo gateway para decidir se uma requisição interna partiu de um IP autorizado. Isso quebra a restrição de IP da Admin API e, em instalações com a chave de API padrão não alterada, resulta em execução remota de código no plano de dados. Está no catálogo KEV da CISA com exploração confirmada e existe módulo Metasploit e template Nuclei públicos, o que torna a varredura automatizada trivial.

O batch-requests é um plugin que aceita, em uma única requisição HTTP ao gateway, uma lista de sub-requisições a serem despachadas internamente — inclusive para caminhos administrativos como /apisix/admin/*. A Admin API do APISIX normalmente é protegida por uma lista de IPs permitidos (allowlist), verificada a partir do cabeçalho X-REAL-IP que o próprio gateway deveria fixar com o IP real do cliente antes de repassar a sub-requisição internamente.

O bug (classificado pela CISA como CWE-290, autenticação/verificação de identidade por spoofing) está na ordem/lógica dessa reescrita: o código do plugin não neutraliza de forma consistente um X-REAL-IP fornecido pelo próprio atacante antes que a checagem de allowlist seja avaliada para a sub-requisição interna. O atacante controla o cabeçalho e o corpo da requisição externa ao batch-requests, incluindo o caminho e o payload da sub-requisição embutida — inclusive endpoints da Admin API.

O resultado prático é um bypass de restrição de IP: uma requisição originada de qualquer lugar da rede pode ser processada internamente como se tivesse partido de um IP confiável (ex.: localhost). Como a Admin API do APISIX permite criar rotas, upstreams e plugins arbitrários, e plugins como serverless-pre-function/serverless-post-function executam código Lua, o acesso não autorizado à Admin API se converte em execução de código no processo do gateway.

O vetor é uma requisição HTTP não autenticada enviada diretamente ao endpoint do plugin batch-requests exposto no plano de dados (a porta pública do gateway), contendo uma sub-requisição direcionada à Admin API. Não é necessária autenticação prévia para acionar o bypass em si — a barreira que cai é justamente o controle de IP que substituiria a autenticação de rede da Admin API.

O impacto final depende de duas pré-condições que a nota do fornecedor destaca e que a manchete 'RCE crítico' esconde: (1) a Admin API precisa estar acessível pelo mesmo caminho de rede que o plano de dados — se ela roda em porta separada isolada de rede, o bypass de IP ainda funciona, mas o atacante só consegue contornar restrições de IP de rotas do plano de dados, sem chegar à Admin API; (2) para virar RCE, o atacante precisa da chave de API da Admin API — em instalação padrão com a chave default não alterada, isso é trivial, tornando o cenário 'default config' plenamente crítico (CVSS 9.8, sem interação do usuário, sem privilégio). Com chave alterada, o atacante ainda pode abusar do bypass para outras finalidades (SSRF interno, contorno de allowlist de rotas), mas não obtém RCE diretamente.

A presença no catálogo KEV da CISA confirma exploração ativa in-the-wild, e a existência de módulo Metasploit e template Nuclei indica que a cadeia completa (bypass de IP → Admin API → criação de plugin malicioso → RCE) já está automatizada e é usada em varredura de massa contra instâncias expostas à internet com configuração padrão.

A correção definitiva é atualizar o Apache APISIX para 2.10.4 (backport da linha 2.10.x) ou 2.12.1, conforme o advisory oficial do projeto. Se a atualização não for imediata, o paliativo indicado pelo próprio fornecedor é desabilitar explicitamente o plugin batch-requests: declarar a lista de plugins habilitados em conf/config.yaml sem incluí-lo, ou comentar sua entrada em conf/config-default.yaml. O custo desse paliativo é funcional — qualquer integração que dependa de agregação de requisições via batch-requests deixa de funcionar até a atualização.

Trocar a chave de API padrão da Admin API e/ou mover a Admin API para uma porta isolada, sem exposição no mesmo segmento de rede do plano de dados, reduz o impacto (evita o salto direto para RCE), mas não corrige a vulnerabilidade em si: o bypass de IP no batch-requests continua permitindo contornar restrições de IP de rotas do plano de dados, segundo o próprio texto do advisory.

Não funciona como mitigação confiar apenas em uma allowlist de IP para proteger a Admin API sem também isolar rede/porta ou desabilitar o plugin vulnerável — é exatamente esse controle que a falha quebra.

Procurar em logs de acesso do APISIX chamadas ao endpoint do plugin batch-requests seguidas, na mesma janela de tempo, de operações na Admin API (/apisix/admin/*) — criação ou alteração inesperada de rotas, upstreams ou plugins (especialmente serverless-pre-function/post-function) fora de mudanças de configuração planejadas é o indicador mais forte de exploração bem-sucedida. Requisições externas contendo cabeçalho X-REAL-IP manipulado combinadas com payloads batch-requests que referenciam caminhos administrativos também são um sinal direto de tentativa de bypass, ainda que nem toda tentativa fique visível se o atacante não obtiver a chave de API correta.

Não há um único log ou assinatura de tráfego universalmente confiável além desse padrão de correlação, já que a requisição inicial ao batch-requests, isoladamente, pode ser legítima — o sinal está na combinação com acesso subsequente à Admin API a partir de um contexto que deveria estar bloqueado pela allowlist de IP.