Encontrei um RCE no WordPress com GPT5.6 e $25

Um post recente no blog afirma que um fluxo de trabalho avançado baseado em GPT-5.6 descobriu uma vulnerabilidade de remote code execution (RCE) no núcleo do WordPress por cerca de $25 em custos de API, provocando debate sobre quanto esses exploits realmente valem e se etiquetas de $500k são marketing exagerado. Comentadores argumentam que modelos de linguagem vão aumentar tanto a oferta de vulnerabilidades quanto a necessidade de testes de segurança contínuos, ao mesmo tempo em que criticam a base de código PHP envelhecida do WordPress e seu vasto ecossistema de plugins como um risco persistente para uma grande parcela da web. Alguns veem a caça a bugs assistida por LLM como um passo em direção a software mais seguro no geral; outros temem que isso acelere a comoditização de exploits e amplie a distância entre donos de sites técnicos e não técnicos.

Valor percebido do exploit (alegação de $500k)

  • Muitos chamam a manchete de clickbait: não há evidência de que esse exploit tenha sido vendido por $500k, e listas públicas de preços de brokers sugerem pagamentos muito menores, especialmente depois dos LLMs.
  • Alguns observam ofertas históricas “de até” centenas de milhares para RCEs 0-day do WordPress, mas não está claro se isso alguma vez foi pago integralmente.
  • Vários argumentam que exploits para WordPress dificilmente alcançam preços de primeira linha em comparação com 0-days de navegador/iOS/Android, embora outros respondam que a enorme presença do WordPress e seu uso governamental o tornam um alvo valioso.

Impacto dos LLMs na descoberta de vulnerabilidades

  • Comentadores veem isso como prova de que a descoberta de exploits assistida por LLM ou conduzida por LLM agora é prática, incluindo cadeias multi-etapas.
  • Outros enfatizam a expertise de domínio, o prompting e o trabalho de validação humano; $25 em tokens ignora anos de experiência e muitas tentativas fracassadas.
  • Alguns esperam que os preços dos exploits caiam à medida que a oferta de bugs aumenta; outros observam que a demanda é limitada e que atacantes profissionais também podem usar LLMs.

Segurança e qualidade de código do WordPress

  • Há forte consenso de que a base de código do WordPress é antiga, bagunçada e difícil de modernizar sem quebrar o ecossistema de plugins/temas.
  • A correção específica de SQL injection é amplamente criticada como feia e emblemática de problemas de design mais profundos (consultas montadas por strings, APIs frágeis como dbDelta).
  • Alguns argumentam que o WordPress é fortemente endurecido pela própria idade e pelo escrutínio; outros apontam erros básicos contínuos (como SQL concatenado por string) como má prática.

WordPress vs alternativas

  • Muitos descrevem implementações reais dolorosas de WP: proliferação de plugins, alto uso de CPU, dores de manutenção e risco de segurança.
  • Outros defendem o WP como exclusivamente acessível para usuários não técnicos (edição WYSIWYG, instalações com um clique, WooCommerce, atualizações fáceis de conteúdo).
  • Geradores de sites estáticos + CMS headless + hospedagem estática barata são propostos como alternativas mais seguras e de baixa manutenção, mas reconhecidas como menos acessíveis para usuários típicos.

Ética, crédito e efeitos no ecossistema

  • Debate sobre se pessoas que usam LLMs para encontrar exploits ou escrever código “merecem” crédito ou pagamento, vs. creditar os modelos ou os autores dos dados de treinamento originais.
  • Alguns se preocupam com “escrita movida por FOMO”, que glamouriza a caça a bugs com LLM como um bilhete de loteria.
  • Vários esperam que o scanning contínuo de segurança e o pentesting se tornem obrigatórios em um mundo onde atacantes podem automatizar a descoberta a baixo custo.