noticias
Afinal, o WordPress ainda é confiável? O problema talvez não seja o WordPress
Há perguntas tecnológicas que parecem simples até alguém tentar respondê-las direito. “O WordPress ainda é confiável?” é uma delas.
Se a resposta for baseada apenas na quantidade de sites invadidos, plugins vulneráveis e histórias de páginas infectadas aparecendo no Google, a tentação é decretar que o WordPress envelheceu mal. Se olharmos apenas para sua participação de mercado, comunidade e ritmo de desenvolvimento, podemos chegar à conclusão oposta e dizer que quase todo mundo continua usando, portanto está tudo certo.
As duas respostas são preguiçosas.
Em setembro de 2026, o WordPress continua sendo utilizado por aproximadamente 40% de todos os sites monitorados pela W3Techs e responde por quase 59% dos sites cujo sistema de gerenciamento de conteúdo é conhecido. É uma vantagem monumental sobre Shopify, Wix, Squarespace, Drupal e praticamente qualquer concorrente que possa ser colocado na mesma conversa.
Ao mesmo tempo, milhares de vulnerabilidades são descobertas anualmente em seu ecossistema, plugins populares continuam apresentando falhas graves e o projeto atravessa uma turbulência de governança que seria desonesto ignorar.
Então, sim: **o WordPress ainda é confiável**.
Mas confiar no WordPress em 2026 exige saber exatamente em qual WordPress você está confiando.
Primeiro: WordPress não é uma coisa só
Boa parte da má reputação da plataforma começa em uma confusão básica.
WordPress Core é o software de código aberto. WordPress.org organiza sua distribuição, desenvolvimento e boa parte do ecossistema comunitário. WordPress.com é um serviço comercial operado pela Automattic. Temas e plugins são componentes adicionais desenvolvidos por milhares de empresas e desenvolvedores independentes.
Quando um plugin de formulário permite execução remota de código, portanto, dizer que “o WordPress foi hackeado” é mais ou menos como culpar o Windows porque alguém instalou um programa duvidoso e entregou a ele privilégios administrativos.
O computador foi comprometido, sem dúvida.
Mas diagnosticar corretamente a origem faz alguma diferença.
E os dados mostram que faz bastante.
O núcleo do WordPress é surpreendentemente pouco interessante para os invasores
O relatório de segurança da Patchstack sobre 2025 registrou 11.334 novas vulnerabilidades no ecossistema WordPress, crescimento de 42% em relação ao ano anterior.
É um número que rende uma manchete assustadora.
A informação realmente importante vem logo depois: **91% dessas vulnerabilidades estavam em plugins e 9% em temas**. Apenas seis vulnerabilidades registradas pelo levantamento estavam no WordPress Core, e elas foram classificadas como problemas de baixa prioridade.
A fotografia muda completamente.
Isso não significa que o núcleo seja invulnerável. Em julho de 2026, por exemplo, o projeto publicou o WordPress 7.0.2 para corrigir uma vulnerabilidade crítica e outra de alta severidade. A gravidade foi suficiente para a equipe ativar atualizações automáticas forçadas nas versões afetadas.
Essa reação, curiosamente, é mais argumento a favor da maturidade do projeto do que contra ela.
Software seguro não é software sem vulnerabilidades. Isso praticamente não existe.
Software seguro é aquele que possui processo de revisão, recebe relatórios, corrige falhas, distribui patches rapidamente e consegue fazer com que essas correções cheguem aos usuários.
Nessa parte da história, o WordPress Core ainda se sai razoavelmente bem.
O incêndio costuma começar nos anexos construídos ao redor dele.
Instalar 38 plugins e culpar o WordPress é uma tradição da internet
Aqui cabe a primeira cutucada.
Existe um esporte muito popular entre proprietários de sites: instalar WordPress, escolher um tema enorme, acrescentar um construtor visual, colocar um pacote de 70 widgets, três plugins de SEO, dois de cache, formulário, pop-up, integração de WhatsApp, estatísticas, compartilhamento social, segurança, backup, galeria, animação e mais alguma coisa que promete “otimizar a performance”.
Quando o site demora seis segundos para abrir, consome memória como se estivesse treinando uma IA e eventualmente apresenta uma vulnerabilidade, o diagnóstico aparece rapidamente:
“WordPress é pesado e inseguro.”
Calma lá.
Cada plugin executável adicionado é código de terceiro rodando dentro da mesma aplicação, frequentemente com acesso ao banco de dados, sistema de arquivos, usuários e funções administrativas.
A superfície de ataque cresce a cada dependência.
E não existe um padrão universal de engenharia entre os desenvolvedores.
Há empresas com equipes de segurança, revisão de código, programas de recompensa por vulnerabilidades e processos rápidos de atualização. Há projetos mantidos praticamente por uma pessoa. Existem plugins abandonados. Existem outros comprados por empresas diferentes anos depois de sua instalação.
Tudo isso pode acabar executando dentro do mesmo WordPress.
Essa liberdade é simultaneamente a maior força e a maior fragilidade da plataforma.
O plugin que resolve seu problema também pode criar o próximo
O problema fica evidente quando uma vulnerabilidade séria aparece em um componente popular.
Em 2026, pesquisadores encontraram falhas críticas em plugins que permitiam upload arbitrário de arquivos e, em determinadas circunstâncias, execução de código no servidor. Em alguns casos documentados pela Wordfence, atacantes começaram a explorar vulnerabilidades no próprio dia da divulgação pública.
Isso muda uma velha recomendação de segurança.
“Atualize seus plugins quando puder” já não é suficiente.
Em aplicações expostas à internet, horas podem importar.
Há outro dado especialmente desconfortável no relatório anual da Patchstack: 46% das vulnerabilidades analisadas em 2025 não haviam recebido correção de seus desenvolvedores a tempo da divulgação.
Aqui mora um dos maiores problemas estruturais do WordPress.
Você pode atualizar religiosamente tudo o que está instalado e continuar vulnerável simplesmente porque **não existe atualização corrigindo aquela falha**.
Nessa situação, a decisão correta pode ser desativar e substituir o componente.
Só que isso exige alguém monitorando o site.
E é justamente aí que muitos projetos WordPress fracassam.
WordPress não é “instalou e esqueceu”
Esta talvez seja a expectativa mais injusta criada ao redor da plataforma.
Como instalar WordPress ficou absurdamente fácil — muitas hospedagens fazem isso com um clique — criou-se a impressão de que operá-lo também é uma atividade de um clique.
Não é.
Um WordPress em produção é uma aplicação web.
Precisa de atualização de sistema, PHP compatível, banco de dados bem administrado, TLS, backups testados, controle de permissões, proteção de credenciais, monitoramento, logs, atualização de dependências e algum plano para responder quando uma dessas dependências apresenta problema.
Se possui comércio eletrônico, cadastro de usuários, dados pessoais ou integrações externas, a responsabilidade aumenta.
O WordPress esconde grande parte dessa complexidade atrás de um painel simpático.
Ele não a elimina.
Quem deixa um site cinco anos parado com PHP antigo, tema abandonado e plugins sem suporte não possui “um WordPress”.
Possui uma cápsula do tempo conectada permanentemente à internet.
E invasores adoram arqueologia.
“Mas existem muitos sites WordPress hackeados”
Claro que existem.
Existem muitos sites WordPress.
Essa distinção estatística é fundamental.
Uma tecnologia presente em aproximadamente 40% da web naturalmente aparecerá em grande quantidade entre sites comprometidos. O número absoluto de incidentes não demonstra, sozinho, que a plataforma seja proporcionalmente menos segura que alternativas.
Existe ainda um efeito econômico.
Atacantes automatizam aquilo que oferece escala.
Uma vulnerabilidade em um plugin presente em centenas de milhares ou milhões de instalações pode justificar o desenvolvimento imediato de scanners e ferramentas de exploração. Uma falha semelhante em um CMS utilizado por 800 sites possui retorno potencial muito menor.
Popularidade transforma o WordPress em alvo.
Não necessariamente em alvo fácil.
Quem determina a facilidade é a configuração.
Em 2026, o WordPress continua evoluindo
Outro argumento recorrente afirma que WordPress é uma plataforma antiga presa a PHP e a uma arquitetura de outra época.
A primeira parte é verdadeira.
O projeto nasceu em 2003.
A conclusão não é.
WordPress 7.1 foi lançado em agosto de 2026 e o projeto continua recebendo mudanças significativas no editor, APIs, ferramentas para desenvolvedores, desempenho e integração com novos recursos de inteligência artificial.
PHP também não é o PHP de 2005.
As versões modernas da linguagem possuem avanços substanciais de performance, tipagem, segurança e recursos para desenvolvimento profissional. Bancos MySQL e MariaDB também evoluíram, assim como servidores web, caches de objetos, CDNs e infraestrutura de hospedagem.
Um WordPress moderno com PHP atual, cache adequado, CDN, banco otimizado e um conjunto pequeno de extensões bem escolhidas pode responder muito rapidamente.
Um WordPress mal montado pode ser uma carroça.
Os dois usam o mesmo CMS.
Isso não absolve a arquitetura do WordPress
Seria igualmente conveniente colocar toda a culpa no usuário.
WordPress carrega decisões arquitetônicas acumuladas em mais de duas décadas de compatibilidade. Uma de suas maiores virtudes sempre foi evitar quebrar sites antigos — e toda compatibilidade retroativa tem custo.
Plugins podem executar código profundamente integrado à aplicação. Temas frequentemente acumulam funcionalidades que deveriam estar separadas da camada visual. O modelo tradicional mistura geração de páginas, acesso a banco de dados, administração e extensões em uma aplicação relativamente monolítica.
Para milhões de projetos, isso funciona maravilhosamente.
Para outros, talvez já não seja a melhor arquitetura.
Um portal de conteúdo de altíssimo tráfego, uma aplicação SaaS complexa, um sistema transacional crítico e um site institucional de uma pequena empresa possuem necessidades completamente diferentes.
Usar WordPress para todos eles apenas porque “é o que sempre usamos” é tão pouco racional quanto rejeitá-lo de todos apenas porque existe Next.js.
Tecnologia não deveria ser religião.
Embora algumas comunidades claramente não tenham recebido o memorando.
O concorrente moderno também traz sua própria coleção de problemas
É muito fácil olhar para uma plataforma SaaS e concluir que tudo ficou mais seguro.
Em alguns aspectos, ficou.
Serviços como Wix, Squarespace, Shopify e Webflow retiram do proprietário do site boa parte da responsabilidade sobre servidor, atualizações de núcleo e infraestrutura. Para pequenas equipes sem profissionais técnicos, isso pode efetivamente representar uma solução mais segura.
O custo aparece em outro lugar.
O usuário troca parte da autonomia por dependência do fornecedor.
Hospedagem, funcionalidades, preços, APIs, limites, regras comerciais e eventualmente até a possibilidade de exportação passam a depender das decisões daquela empresa.
O WordPress self-hosted continua oferecendo algo extraordinariamente valioso: você pode baixar o código, colocá-lo em outro servidor, acessar diretamente seus arquivos e banco de dados e continuar operando sem pedir autorização ao fornecedor de uma plataforma.
Em 2026, quando serviços digitais tentam transformar praticamente tudo em assinatura, essa independência envelheceu surpreendentemente bem.
E os sites estáticos?
Para determinados projetos, existe uma resposta ainda mais incômoda para WordPress.
Talvez você simplesmente não precise dele.
Um site institucional com dez páginas, alterado três vezes por ano e sem autenticação não precisa necessariamente carregar um CMS completo, banco de dados e painel administrativo em cada requisição.
Geradores estáticos e arquiteturas que publicam HTML pré-construído podem oferecer uma superfície de ataque extremamente menor e desempenho excelente.
Não existe banco para consultar durante a visita.
Não existe login administrativo público no servidor que entrega as páginas.
Não existem 25 plugins PHP esperando pacientemente uma requisição maliciosa.
Mas essa simplicidade cobra em fluxo editorial, desenvolvimento e facilidade de manutenção para usuários não técnicos.
Se vinte jornalistas precisam publicar dezenas de textos diariamente, possuir um CMS volta a fazer muito sentido.
A pergunta correta nunca deveria ser “qual tecnologia é melhor?”.
É “qual complexidade este projeto realmente precisa carregar?”.
Existe ainda um elefante chamado governança
Segurança técnica não é a única dimensão da palavra confiança.
E aqui o WordPress atravessa um período desconfortável.
Matt Mullenweg é cofundador do WordPress, liderança histórica do projeto e cofundador da Automattic, empresa por trás do WordPress.com, WooCommerce, Jetpack e outras partes importantes do ecossistema.
Essa proximidade sempre gerou uma estrutura bastante peculiar.
WordPress é software livre. A marca pertence à WordPress Foundation. Milhares de pessoas e empresas contribuem para o projeto. A Automattic não é “dona do WordPress”.
Ao mesmo tempo, seria ingênuo fingir que a companhia e Mullenweg possuem influência equivalente à de qualquer desenvolvedor aleatório enviando um patch numa terça-feira.
Não possuem.
O próprio manual de organização do projeto WordPress ainda descreve Mullenweg como seu líder.
Então veio a briga com a WP Engine
A disputa entre Automattic, Mullenweg e WP Engine transformou uma discussão que parecia interna ao ecossistema em uma questão pública de governança.
O conflito iniciado em 2024 envolveu marca, contribuições ao projeto open source, acesso a recursos do WordPress.org e posteriormente ações judiciais.
Independentemente de quem venha a prevalecer nos diferentes argumentos jurídicos, o episódio demonstrou algo importante para quem escolhe infraestrutura:
**open source não significa automaticamente governança descentralizada**.
O código estar disponível sob licença livre impede uma empresa de simplesmente desligar o WordPress instalado no seu servidor.
Isso é excelente.
Mas recursos centrais do ecossistema — diretórios, distribuição, serviços, marcas, decisões comunitárias e relações comerciais — possuem estruturas de poder próprias.
Código aberto elimina certos tipos de dependência.
Não elimina política.
E a história ganhou um capítulo novo justamente agora
Em 9 de setembro de 2026, o conselho da Automattic colocou Matt Mullenweg em licença remunerada contra sua vontade.
Mark Davies, então diretor financeiro da companhia, assumiu interinamente a posição de CEO.
O episódio não significa que “o dono do WordPress caiu”, porque essa frase estaria errada em praticamente todas as palavras importantes.
Automattic é uma empresa. WordPress é um projeto open source. WordPress.com é um serviço comercial. A WordPress Foundation possui a marca.
Mas seria igualmente errado dizer que uma crise de liderança na Automattic não tem qualquer relevância para o ecossistema.
Tem.
A turbulência chega depois de anos de disputa com a WP Engine, debates sobre contribuições ao projeto e questionamentos sobre a concentração de influência ao redor de Mullenweg.
Nada disso cria uma vulnerabilidade SQL em seu site amanhã pela manhã.
Mas confiança tecnológica também significa previsibilidade institucional.
E nessa coluna a nota do WordPress merece uma revisão mais cuidadosa.
Talvez este seja o maior paradoxo do WordPress
Tecnicamente, ninguém consegue levar seu WordPress embora.
Você possui o código.
Pode manter uma cópia.
Pode modificá-lo.
Pode criar um fork.
Pode mover seu site de uma hospedagem para outra.
Essa é uma vantagem extraordinária sobre plataformas proprietárias.
Ao mesmo tempo, o ecossistema que faz WordPress ser WordPress depende de uma complexa rede de empresas, repositórios, desenvolvedores, mantenedores, infraestrutura comunitária e lideranças.
Você é independente para executar o software.
Não é totalmente independente do ecossistema se pretende continuar recebendo tudo o que torna esse software conveniente.
É uma diferença sutil.
Mas importante.
O WordPress também sofre porque tornou desenvolver sites fácil demais
Aqui está uma crítica que raramente fazemos à plataforma: parte dos problemas do WordPress nasceu justamente de seu sucesso.
Ele reduziu tanto a barreira para construir sites que tornou possível entregar sistemas complexos sem compreender completamente a infraestrutura que os executa.
Isso democratizou a publicação.
Também democratizou algumas decisões técnicas terríveis.
Um profissional consegue montar loja, área de membros, formulários, automações, pagamentos e integrações quase inteiramente com plugins.
O painel funciona.
A página abre.
O cliente paga.
Todo mundo comemora.
Até o dia em que alguma atualização quebra a integração entre cinco componentes desenvolvidos por cinco empresas diferentes.
A facilidade visual pode esconder uma arquitetura extremamente complexa.
E complexidade escondida continua sendo complexidade.
Então devemos abandonar plugins?
Não.
Devemos abandonar plugins ruins.
Extensibilidade é parte fundamental do motivo pelo qual WordPress permanece relevante depois de mais de duas décadas. Seria absurdo exigir que cada empresa desenvolvesse do zero formulário, SEO, comércio eletrônico, autenticação, cache e integração com serviços externos.
O critério precisa mudar de quantidade para procedência.
Quem mantém o plugin?
Há quanto tempo ele existe?
Recebe atualizações?
Existe processo público de segurança?
O desenvolvedor responde a vulnerabilidades?
Qual acesso o plugin recebe?
É realmente necessário?
Existe uma alternativa que elimine três dependências em vez de acrescentar a quarta?
Uma instalação profissional deveria tratar plugin como uma empresa séria trata biblioteca de software.
Dependência não é figurinha.
Não precisamos completar o álbum.
Uma instalação WordPress confiável em 2026 se parece bem diferente daquela de dez anos atrás
A receita não é particularmente exótica.
Versões atuais de WordPress e PHP, hospedagem adequadamente isolada, TLS, contas individuais, autenticação multifator para administradores, senhas fortes, privilégios mínimos, backups externos testados, ambiente de homologação, monitoramento de vulnerabilidades e um conjunto controlado de plugins provenientes de fornecedores confiáveis.
Atualizações precisam fazer parte da operação.
Não de uma faxina anual.
Sites críticos também se beneficiam de firewall de aplicação, CDN, proteção contra força bruta, logs centralizados, monitoramento de integridade e políticas que impeçam edição arbitrária de arquivos em produção.
Isso custa dinheiro ou trabalho.
Segurança sempre custa.
A alternativa costuma apenas mandar a fatura depois.
E o desempenho?
WordPress também recebe críticas merecidas aqui.
É perfeitamente possível construir uma página simples que realize dezenas ou centenas de consultas ao banco, carregue JavaScript de meia dúzia de fornecedores e entregue megabytes de recursos antes de mostrar ao visitante um título e uma fotografia.
Mas isso normalmente não acontece porque `wp_posts` acordou mal-humorado naquela manhã.
A arquitetura escolhida para o site importa.
Um bom sistema de cache pode fazer com que páginas públicas sequer precisem executar grande parte da aplicação para cada visitante. CDN pode aproximar conteúdo do usuário. Otimização de imagens, carregamento seletivo de scripts e temas bem construídos reduzem drasticamente o custo das páginas.
O que não funciona é instalar um plugin de performance em cima de 27 plugins de performance duvidosa e esperar que o universo recompense a iniciativa.
Em algum momento, precisamos conversar sobre causa e efeito.
Quem deveria continuar escolhendo WordPress
Para portais de conteúdo, sites institucionais, revistas, blogs, projetos editoriais, pequenas e médias lojas, organizações que valorizam independência de fornecedor e equipes que precisam de um painel conhecido, WordPress continua sendo uma escolha tecnicamente defensável.
Em vários desses cenários, continua sendo excelente.
O ecossistema oferece uma quantidade de ferramentas, profissionais, hospedagens, integrações e conhecimento acumulado que concorrentes menores simplesmente não conseguem reproduzir.
Trocar isso por uma arquitetura customizada também cria riscos.
Código próprio possui vulnerabilidades.
Frameworks recebem CVEs.
Pacotes NPM são comprometidos.
Dependências desaparecem.
Desenvolvedores vão embora.
Servidores continuam precisando de atualização.
Sair do WordPress não concede automaticamente imunidade digital.
Às vezes apenas troca problemas conhecidos por problemas que sua equipe ainda não conhece.
Quem deveria pensar duas vezes
Projetos com requisitos transacionais muito específicos, aplicações altamente interativas, sistemas de missão crítica, arquiteturas que exigem controle rigoroso sobre cada componente ou operações que não necessitam de CMS podem encontrar alternativas mais adequadas.
Também vale reconsiderar WordPress quando a única maneira de atender ao projeto é instalar uma quantidade absurda de extensões que começam a transformar o CMS em algo que ele nunca foi projetado para ser.
Se são necessários 42 plugins para convencer WordPress de que ele é um ERP, talvez seja hora de considerar a hipótese revolucionária de usar um ERP.
A ferramenta não precisa ser culpada por tudo.
Mas também não precisa ser torturada.
Análise da equipe: confiável, sim; confiável por padrão, não
A pergunta inicial finalmente pode receber uma resposta menos confortável.
**O WordPress ainda é confiável em 2026. Uma instalação WordPress qualquer, não necessariamente.**
Essa distinção resume quase toda a questão.
O núcleo possui uma equipe de segurança madura, processo ativo de atualização e uma quantidade relativamente pequena de vulnerabilidades quando comparado ao gigantesco ecossistema construído em torno dele.
O problema está naquilo que o usuário acrescenta, abandona ou deixa de administrar.
Plugins formam a maior superfície de ataque. Hospedagem ruim amplia o dano. Credenciais fracas continuam abrindo portas. Atualizações atrasadas transformam vulnerabilidades corrigidas em problemas atuais. Backups que ninguém nunca tentou restaurar proporcionam apenas uma agradável sensação de segurança.
E existe agora uma segunda camada de preocupação.
A turbulência institucional envolvendo Automattic, Mullenweg e WP Engine mostrou que um projeto pode ter código aberto e ainda concentrar influência em poucos atores. Os acontecimentos recentes dentro da própria Automattic reforçam a importância de discutir governança com a mesma maturidade com que discutimos PHP, banco de dados e plugins.
Isso não é motivo para abandonar WordPress.
É motivo para parar de tratá-lo como eletrodoméstico.
Talvez a fama de inseguro esteja fazendo a pergunta errada
Depois de mais de 20 anos, WordPress carrega cicatrizes que tecnologias jovens ainda não tiveram tempo de adquirir.
Cada falha aparece em um ecossistema gigantesco. Cada plugin problemático vira notícia. Cada decisão controversa encontra imediatamente milhões de usuários interessados.
Essa exposição pode criar a impressão de decadência.
Os números de mercado mostram outra coisa: apesar de concorrência muito mais sofisticada do que aquela enfrentada na década passada, WordPress ainda domina amplamente o mercado de CMS.
Dominância, obviamente, não é certificado de qualidade.
Mas também seria difícil sustentar por mais de duas décadas uma infraestrutura usada em parcela tão grande da web se sua essência fosse simplesmente uma bomba-relógio.
O verdadeiro problema talvez seja uma expectativa que o próprio WordPress ajudou a criar: a ideia de que qualquer pessoa pode construir praticamente qualquer coisa com meia dúzia de cliques.
Pode.
A questão é quem cuidará daquilo depois.
Em 2026, confiar no WordPress não deveria significar confiar cegamente no logotipo azul, em qualquer plugin encontrado numa busca ou no sujeito que promete “site profissional completo” pelo preço de um jantar.
Significa confiar em uma arquitetura conscientemente montada, com componentes escolhidos, manutenção contínua e infraestrutura adequada.
WordPress continua sendo uma plataforma.
Não uma equipe de TI.
E talvez a maior prova de sua maturidade seja justamente esta: depois de 23 anos, ele continua funcionando muito bem quando alguém igualmente maduro está tomando conta dele.
👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis