Entender exploração de vulnerabilidades em binários está cada vez mais importante. Os principais projetos de software estão sendo bombardeados com vulnerabilidades encontradas por inteligências artificiais. As LLMs têm se demonstrado capazes de encontrar e explorar vulnerabilidades que antes apenas um pequeno número de especialistas conseguia encontrar e explorar.
Nesta última semana foram publicadas vulnerabilidades críticas no PHP e no Node.js, além de outros projetos, que chamaram bastante a atenção.
php2shell (CVE-2026-109618 e CVE-2026-109619)
As vulnerabilidades que potencialmente afetam grande parte da web e que levaram diversos sites a sair do ar para atualizações emergenciais [1][2] são conhecidas como php2shell. Elas foram descobertas de forma independente por pesquisadores da Calif, da Wiz e do OpenAI Codex Security [3][4]. Durante a semana passada, essas vulnerabilidades foram o assunto principal.
Assim como quase todo acontecimento que chama bastante atenção na comunidade, surgiram diversos artigos e posts em redes sociais sobre essas vulnerabilidades. Alguns posts apontavam a dificuldade de exploração dessas vulnerabilidades, outros mencionavam a possibilidade de vazamento de informação por meio das LLMs, já que outras empresas e equipes redescobriram as mesmas vulnerabilidades após a descoberta inicial por outra equipe em um curto espaço de tempo. Em meio a essas discussões, surgiram diversos posts afirmando terem escrito exploits para as vulnerabilidades. Porém, muitas das provas de conceito públicas claramente não funcionam.
Houve casos de posts claramente confundindo acionar a vulnerabilidade com explorá-la, LLMs aparentemente buscando um caminho mais simples, porém não realista, para alcançar objetivos e assim por diante. Apesar do sucesso das LLMs, se o usuário não tiver conhecimento e não entender o que está fazendo, pode facilmente ser enganado pelos resultados e a consequência para a reputação de um pesquisador ou empresa pode ser séria.
Além disso, com base em discussões públicas e em um post da CrowdStrike [5], parece que as vulnerabilidades têm uma dificuldade inerente na criação de um exploit estável e confiável. Até o momento, as confirmações de explorações com provas de conceito alcançando execução de código arbitrário vieram de empresas especializadas. E, pelo menos em um desses casos, foi um esforço de uma equipe de pessoas experientes [6].
Um ponto interessante é encontrado no artigo no blog da Calif. Na seção sobre como a vulnerabilidade foi encontrada, o autor deixa clara a importância da experiência com o código em que se está trabalhando e algumas limitações no uso de LLMs para pesquisa de vulnerabilidades. Em casos de análises de variantes, as LLMs não parecem começar as análises a partir de conhecimentos obscuros de décadas atrás [4].
Um bug relacionado ao php2shell foi reportado em 2020, redescoberto posteriormente por uma auditoria independente, mas não foi corrigido por falta de uma evidência clara de impacto e exploração. Isso também demonstra o quanto a experiência do profissional utilizando as LLMs é importante. A Calif foi capaz de encontrar variantes do problema ao generalizar o padrão do primeiro bug em um SKILL.md que ajudou a eficiência e capacidade dos modelos utilizados por eles. Ou seja, um trabalho conjunto de especialista com as LLMs. Por mais poderosas que as LLMs sejam, a experiência do usuário continua sendo relevante e, muitas vezes, um fator determinante [4].
node2shell / brocoli2shell (CVE-2026-111497)
A vulnerabilidade é um out-of-bounds write no decodificador Brotli embutido no Node.js, encontrada pelo OpenAI Codex Security. O que agravou a situação foi uma decisão tomada no passado: desabilitar um recurso de segurança importante, o Position-Independent Executable (PIE), para não perder desempenho.
Com o Address Space Layout Randomization (ASLR), o kernel randomiza as bases das regiões de memória no espaço de endereçamento do processo em tempo de execução. Essas regiões incluem a glibc, a biblioteca padrão do C, que fornece funções fundamentais para os programas executarem, assim como outras bibliotecas carregadas em tempo de execução e outras regiões, como a pilha e a heap. Porém, um binário compilado sem PIE é ligado para um endereço fixo e não pode ser randomizado. O PIE resolve esse problema ao tornar o binário relocável, permitindo que o ASLR também o randomize. Dessa forma, o leiaute do espaço de endereçamento do binário em execução não deverá conter praticamente nenhum endereço não randomizado. Saber a localização dos objetos em memória é, muitas vezes, um pré-requisito para alcançar uma exploração estável e confiável.
O argumento para desabilitar o PIE no Node.js era um impacto de 5 a 10% na performance, inicialmente, na arquitetura x86 de 32 bits [7]. Após um benchmark realizado por um usuário, aparentemente em x86 de 64 bits, o problema de performance ao habilitar PIE também permaneceu. No macOS, porém, o PIE é habilitado. O argumento encontrado na issue que discute esse problema menciona que o macOS não é uma plataforma em que o desempenho seja crítico e, por isso, a perda seria aceitável. Há uma discussão sobre habilitar o equivalente ao PIE e outros mecanismos de segurança para o Node.js no Windows [9].
É importante mencionar que nem todo binário do Node.js é compilado sem PIE. Isso ocorre nos binários oficiais para Linux com glibc distribuídos pelo próprio projeto. Mesmo no Linux, quando o Node.js é instalado pelo repositório de pacotes da distribuição, na grande maioria dos casos o binário é compilado com PIE [8].
A ausência de PIE no binário do Node.js já foi explorada no passado, como demonstrado no artigo da SonarSource [10].
Esses acontecimentos recentes demonstram o quanto é importante saber sobre desenvolvimento de exploits e segurança de binários.
Uma pessoa solicitou ao projeto da glibc a criação de um recurso de segurança que impediria a execução de binários que não são PIE. Se habilitada, essa medida poderia fazer com que alguns programas parassem de funcionar, mas ofereceria segurança elevada para aqueles interessados em habilitar o recurso. A resposta de um desenvolvedor da glibc foi que esse e outros recursos de hardening já estão em seu backlog, como opções que o administrador poderia habilitar [11].
Caso todos esses recursos sejam adicionados à glibc, a segurança de binários aumentará consideravelmente. Isso tornaria a segurança de distribuições Linux que utilizem esses recursos por padrão muito maior. Obviamente, mesmo que esses recursos sejam incorporados à glibc, levará tempo para a correta adequação dos projetos afetados.
Em nosso treinamento, demonstramos como as mitigações funcionam, incluindo ASLR e PIE, que são assuntos bastante discutidos na comunidade de segurança atualmente. Além disso, demonstramos na prática como elas podem ser burladas.
Treinamento de Desenvolvimento de Exploits e Segurança de Binários em Linux (Linux Binary Exploitation) – Abril 2027
Os casos do php2shell e do node2shell evidenciam o importante papel desempenhado pelo pesquisador mesmo nessa nova era de pesquisa guiada por LLM. Vulnerabilidades estão sendo encontradas em um ritmo muito mais rápido do que as empresas e projetos conseguem corrigir. A quantidade de ruído também tem crescido bastante. Entender adequadamente o impacto das vulnerabilidades, validar provas de conceito e compreender como as mitigações afetam a exploração tornou-se essencial.
Em nosso treinamento de Desenvolvimento de Exploits e Segurança de Binários em Linux, ensinamos a profissionais de TI e Segurança da Informação o caminho para desenvolver essas habilidades. Partimos dos fundamentos e do contexto histórico até chegar aos conceitos essenciais para entender o estado atual e o futuro da área de pesquisa de vulnerabilidades que, hoje em dia, deixou de ser um nicho, mas continua exigindo conhecimento profundo para gerar resultados confiáveis.
Você aprenderá na prática como um binário no Linux funciona (formato ELF), a verificar a segurança por meio das mitigações existentes, como No-eXecute (NX), ASLR e PIE, qual é o papel da glibc em ambientes Linux e como desenvolver exploits profissionais, isto é, confiáveis e estáveis.
Não perca essa oportunidade e garanta sua vaga. Oferecemos desconto especial para os 5 primeiros inscritos e parcelamento no cartão de crédito em até 8x sem juros.
Título: Treinamento de Desenvolvimento de Exploits e Segurança de Binários em Linux (Linux Binary Exploitation)
Carga horária: 48 horas / 12 dias
Horário: Segundas, quartas e quintas-feiras das 19h às 23h (horário de Brasília)
Quando: 05 a 29 de abril de 2027
Onde: Online
Inscrições e mais informações:
https://allelesecurity.com/treinamento-binario-abril-2027/
Referências
[1] – PHP2Shell: Why many websites had to go offline
https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates
[2] – Websites shut down globally after AI finds cybersecurity flaw affecting 70% of the internet
https://edition.cnn.com/2026/10/21/tech/php2shell-vulnerability-ai-intl
[3] – PHP2Shell — AI uncovers critical vulnerabilities in the backbone of the web
https://www.php2shell.com/
[4] – A tale of two PHP remote vulnerabilities
https://calif.io/php2shell/
[5] – Obstacles to Weaponizing PHP2Shell Likely Constrain Immediate Widespread Exploitation
https://www.crowdstrike.com/en-us/blog/obstacles-to-weaponizing-php2shell-likely-constrain-exploitation/
[6] – Tweet from Dan Guido.
https://x.com/dguido/status/2113825891021144306
[7] – ASLR (pie) disabled in v12 Linux amd64 build from nodejs.org
https://github.com/nodejs/node/issues/33425
[8] – Proposal: build official Node.js binaries for glibc-based Linux using PIE, enables ASLR, helps prevent RCE
https://github.com/nodejs/node/issues/66951
[9] – Windows build: node.exe missing Control Flow Guard (CFG) and DYNAMICBASE mitigations
https://github.com/nodejs/node/issues/64212
[10] – Why Code Security Matters – Even in Hardened Environments
https://www.sonarsource.com/blog/why-code-security-matters-even-in-hardened-environments
[11] – Tunable for banning non-PIE executables
https://sourceware.org/pipermail/libc-alpha/2026-October/181528.html