Guillem Alsina Gonzàlez
O modelo de segurança do WordPress tem uma fragilidade conhecida. Os novos plugins são analisados antes de entrarem no diretório oficial, mas as versões seguintes podiam ser distribuídas sem um controlo equivalente. Um plugin legítimo podia, portanto, tornar-se um vetor de ataque através de uma atualização comprometida, de código malicioso introduzido posteriormente ou simplesmente de uma vulnerabilidade grave.
O WordPress começou a alterar esse modelo a 5 de junho, impondo um período de espera de seis horas antes da distribuição de novas versões de plugins e temas. Durante essa janela, ferramentas automatizadas, scanners de segurança e sistemas apoiados por inteligência artificial analisam as alterações ao código e atribuem uma classificação de risco. As atualizações consideradas de elevado risco passam agora a ser automaticamente bloqueadas, sem necessidade de intervenção humana prévia.
A mudança ganhou relevância depois de, a 28 de julho, o sistema ter detetado uma porta traseira numa atualização de um plugin utilizado por cerca de 20 mil sites empresariais. O código foi identificado durante o período de espera e a versão comprometida não chegou aos ambientes de produção. O lançamento foi interrompido 26 minutos depois do alerta chegar à equipa de segurança.
Para os CIO e CISO, o caso expõe um problema que ultrapassa o WordPress. As organizações podem proteger servidores, identidades e redes, mas continuam dependentes de milhares de componentes de software desenvolvidos e atualizados por terceiros. Cada atualização é potencialmente uma alteração à superfície de ataque da empresa.
É precisamente aqui que o novo modelo ganha importância. Em vez de assumir que um fornecedor previamente aprovado continua a ser seguro, o sistema volta a avaliar o código sempre que este muda. A lógica aproxima-se do princípio de zero trust: a confiança deixa de ser permanente e passa a depender da verificação contínua.
O mecanismo também não distingue entre ataque e erro de programação. Se uma atualização ultrapassar o limite técnico de risco, é bloqueada. Os programadores recebem informação sobre o problema e podem corrigir o código e submeter uma nova versão.
Para as empresas que mantêm WordPress em sites institucionais, portais de clientes ou plataformas de comércio eletrónico, esta camada não elimina a necessidade de políticas próprias de gestão de vulnerabilidades, inventário de plugins, testes ou controlo de atualizações. Mas introduz uma barreira adicional num ponto crítico da cadeia de fornecimento: antes de software potencialmente comprometido chegar aos sistemas das organizações.
