{"id":22083,"date":"2026-10-23T05:56:32","date_gmt":"2026-10-22T21:56:32","guid":{"rendered":"https:\/\/synopower.club\/?p=22083"},"modified":"2026-10-23T05:56:32","modified_gmt":"2026-10-22T21:56:32","slug":"synology-php2shell-emergency-patch","status":"publish","type":"post","link":"https:\/\/synopower.club\/pt\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell no Synology: Como corrigimos seis sites em um \u00fanico dia"},"content":{"rendered":"

PHP2Shell<\/strong> PHP2Shell \u00e9 o nome que a ind\u00fastria adotou para CVE-2026-109618 e CVE-2026-109619, um par de falhas cr\u00edticas no pr\u00f3prio mecanismo PHP que permitem a execu\u00e7\u00e3o remota de c\u00f3digo sem autentica\u00e7\u00e3o. Detalhes vazaram em 20 de outubro de 2026, um dia antes da divulga\u00e7\u00e3o coordenada, e o projeto PHP lan\u00e7ou vers\u00f5es de emerg\u00eancia em 21 de outubro. Como o bug reside no interpretador e n\u00e3o em qualquer aplicativo, aplicar patches no WordPress, Joomla ou MediaWiki n\u00e3o resolve o problema. A \u00fanica solu\u00e7\u00e3o real \u00e9 uma nova compila\u00e7\u00e3o do PHP. Mantemos seis sites WordPress p\u00fablicos em hardware Synology, e o PHP2Shell fez com que todos eles tivessem que ser reconstru\u00eddos na mesma semana. Este guia aborda o que o bug realmente \u00e9, como corrigi-lo no DSM por meio do Package Center, como lidar com ele quando seu site \u00e9 executado em um cont\u00eainer e a compara\u00e7\u00e3o desconfort\u00e1vel entre o que o Synology lan\u00e7ou e o que outros fornecedores de NAS conseguiram at\u00e9 agora.<\/p>\n\n\n\n

\n

Ponto SynoPower Club:<\/strong>Nossos seis sites foram corrigidos em um \u00fanico dia \u00fatil ap\u00f3s a publica\u00e7\u00e3o do aviso do PHP2Shell, e o que tornou isso poss\u00edvel n\u00e3o foi hero\u00edsmo, mas sim a publica\u00e7\u00e3o dos pacotes corrigidos pela ASUSTOR (Synology) na mesma data do aviso. O aviso Synology-SA-26:14 foi publicado em 22 de outubro com o status "Resolvido" e uma tabela completa de vers\u00f5es corrigidas at\u00e9 o PHP 7.4. No mesmo dia, a QNAP publicou o aviso QSA-26-18 com o status "Em corre\u00e7\u00e3o" e a mensagem "A ser anunciado" em cada c\u00e9lula de vers\u00e3o corrigida, e a ASUSTOR respondeu excluindo o PHP legado do App Central em vez de corrigi-lo. Se voc\u00ea hospeda um site p\u00fablico em um NAS, essa diferen\u00e7a n\u00e3o \u00e9 um detalhe de marketing. \u00c9 a diferen\u00e7a entre atualizar um pacote e tirar seu site da internet enquanto voc\u00ea espera.<\/p>\n<\/blockquote>\n\n\n\n

O que \u00e9 PHP2Shell e por que ele \u00e9 diferente?<\/h2>\n\n\n\n

O PHP2Shell n\u00e3o \u00e9 um bug isolado, mas sim um conjunto de falhas relacionadas \u00e0 seguran\u00e7a de mem\u00f3ria no PHP, que ocorre na forma como o sistema limpa os recursos ap\u00f3s uma requisi\u00e7\u00e3o que esgotou a mem\u00f3ria dispon\u00edvel. O PHP utiliza longjmp()<\/code> Para evitar erros fatais, incluindo falta de mem\u00f3ria, esse salto ignora o c\u00f3digo de limpeza que normalmente colocaria o mecanismo de volta em um estado conhecido. Parte desse estado \u00e9 global e persiste na pr\u00f3xima solicita\u00e7\u00e3o processada pelo mesmo processo de trabalho.<\/p>\n\n\n\n

A vulnerabilidade CVE-2026-109618 est\u00e1 relacionada \u00e0 falta de mem\u00f3ria. Uma requisi\u00e7\u00e3o HTTP maliciosa esgota o limite de mem\u00f3ria enquanto os dados da requisi\u00e7\u00e3o est\u00e3o apenas parcialmente inicializados, fazendo com que a rotina de limpeza percorra estruturas que nunca foram conclu\u00eddas. J\u00e1 a vulnerabilidade CVE-2026-109619 est\u00e1 relacionada ao uso ap\u00f3s libera\u00e7\u00e3o de mem\u00f3ria: o estado global que aponta para a mem\u00f3ria liberada pela requisi\u00e7\u00e3o pode ser lido por uma requisi\u00e7\u00e3o posterior no mesmo worker, permitindo a execu\u00e7\u00e3o de c\u00f3digo ou a divulga\u00e7\u00e3o de mem\u00f3ria.<\/p>\n\n\n\n

Duas caracter\u00edsticas tornam o PHP2Shell pior do que os avisos usuais sobre PHP. Primeiro, ele \u00e9 pr\u00e9-autentica\u00e7\u00e3o. Ambas as falhas s\u00e3o acionadas antes que qualquer autentica\u00e7\u00e3o em n\u00edvel de aplica\u00e7\u00e3o seja executada, portanto, uma tela de login, um plugin de membros ou uma senha de administrador n\u00e3o protegem nada. Segundo, a variante de divulga\u00e7\u00e3o de mem\u00f3ria vaza a mem\u00f3ria do processo worker, e um worker PHP em um site WordPress armazena credenciais de banco de dados, tokens de API e chaves de pagamento. Uma leitura bem-sucedida n\u00e3o precisa chegar \u00e0 execu\u00e7\u00e3o do c\u00f3digo para arruinar sua semana.<\/p>\n\n\n\n

As duas vulnerabilidades CVE do PHP2Shell receberam uma pontua\u00e7\u00e3o de 9,2 no CVSS v4.0 pela equipe de seguran\u00e7a do PHP. A Synology, por sua vez, atribuiu-lhes uma pontua\u00e7\u00e3o de 9,8 no CVSS v3.1 em seu pr\u00f3prio comunicado. Escalas diferentes, mesma conclus\u00e3o. Os relatos de explora\u00e7\u00e3o s\u00e3o contradit\u00f3rios: a watchTowr afirma ter detectado tentativas contra sua rede honeypot, enquanto a Bitdefender n\u00e3o relatou nada em sua telemetria at\u00e9 o momento da reda\u00e7\u00e3o deste texto, e a QNAP declara n\u00e3o ter recebido relatos de explora\u00e7\u00e3o direcionada especificamente a produtos da QNAP.<\/p>\n\n\n\n

\"Synology-SA-26:14
Synology-SA-26:14, publicado em 22 de outubro de 2026 \u00e0s 19:45 UTC+8 com o status Resolvido.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell versus um exploit normal do WordPress<\/h2>\n\n\n\n

A maior parte dos ataques a sites WordPress p\u00fablicos s\u00e3o vulnerabilidades de plugins. O padr\u00e3o \u00e9 conhecido: um plugin inclui um endpoint REST quebrado, um scanner o encontra, voc\u00ea atualiza o plugin e a vulnerabilidade \u00e9 corrigida. O PHP2Shell quebra completamente esse padr\u00e3o, e a pr\u00e1tica de auditar plugins automaticamente se torna um esfor\u00e7o desperdi\u00e7ado nesse caso.<\/p>\n\n\n\n

Aspecto<\/th>CVE t\u00edpico de plugin<\/th>PHP2Shell<\/th><\/tr><\/thead>
Onde vive o inseto<\/td>C\u00f3digo da aplica\u00e7\u00e3o (plugin ou tema)<\/td>O pr\u00f3prio interpretador PHP<\/td><\/tr>
Quem pode desencadear isso?<\/td>Geralmente requer uma fun\u00e7\u00e3o de assinante ou administrador.<\/td>Ningu\u00e9m. Pr\u00e9-autentica\u00e7\u00e3o, antes da execu\u00e7\u00e3o da l\u00f3gica do aplicativo.<\/td><\/tr>
Atualizar o WordPress ajuda?<\/td>Geralmente sim<\/td>N\u00e3o. Atualiza\u00e7\u00f5es do n\u00facleo e de plugins s\u00e3o irrelevantes.<\/td><\/tr>
Um WAF (filtro de imagem da esposa) impede isso?<\/td>Normalmente, uma vez que uma regra existe,<\/td>Em parte. As regras de formato de requisi\u00e7\u00e3o n\u00e3o consideram o caminho OOM.<\/td><\/tr>
O que realmente resolve o problema?<\/td>Atualiza\u00e7\u00e3o do plugin<\/td>Uma nova compila\u00e7\u00e3o do PHP, nada mais.<\/td><\/tr>
raio de explos\u00e3o<\/td>Um site, uma funcionalidade<\/td>Todos os sites PHP no servidor, todos de uma vez.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Essa \u00faltima linha explica por que o PHP2Shell se transformou em um dia inteiro de trabalho em vez de uma tarde. Um \u00fanico pacote PHP compartilhado em um NAS pode estar por tr\u00e1s de uma d\u00fazia de hosts virtuais do Web Station, e uma \u00fanica imagem de cont\u00eainer pode ser a base para v\u00e1rios sites. A aplica\u00e7\u00e3o de patches n\u00e3o \u00e9 por site, mas sim por ambiente de execu\u00e7\u00e3o, e voc\u00ea precisa enumerar os ambientes de execu\u00e7\u00e3o antes de poder afirmar que algo foi feito.<\/p>\n\n\n\n

Como saber se seu NAS est\u00e1 exposto<\/h2>\n\n\n\n

A avalia\u00e7\u00e3o da sua exposi\u00e7\u00e3o ao PHP2Shell come\u00e7a por separar duas quest\u00f5es distintas. O sistema cont\u00e9m uma vers\u00e3o vulner\u00e1vel do PHP e essa vers\u00e3o \u00e9 acess\u00edvel pela internet? A Synology faz essa distin\u00e7\u00e3o explicitamente: o DSM inclui um componente PHP interno usado pelo sistema operacional, e a Synology afirma que ele n\u00e3o possui m\u00f3dulos acess\u00edveis externamente e, portanto, nenhuma superf\u00edcie de ataque exposta. O risco atribu\u00eddo a esse componente \u00e9 m\u00ednimo, e a corre\u00e7\u00e3o est\u00e1 prevista para uma vers\u00e3o posterior do DSM, para que as verifica\u00e7\u00f5es de vulnerabilidades parem de sinaliz\u00e1-lo.<\/p>\n\n\n\n

Os pacotes relevantes para o PHP2Shell s\u00e3o aqueles que fornecem PHP para a web. A lista Synology inclui Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station e WordPress. Se voc\u00ea tiver algum desses instalados e acess\u00edveis, voc\u00ea est\u00e1 dentro do escopo.<\/p>\n\n\n\n

Verifique as vers\u00f5es diretamente em vez de confiar em um painel de controle. No Centro de Pacotes, os pacotes PHP instalados mostram suas vers\u00f5es no bloco e o aviso de atualiza\u00e7\u00e3o indica a vers\u00e3o de destino. A partir de um terminal, consulte o pr\u00f3prio ambiente de execu\u00e7\u00e3o:<\/p>\n\n\n\n

Pacote PHP # Synology (ajuste o caminho para a vers\u00e3o que voc\u00ea est\u00e1 executando) \/volume1\/@appstore\/PHP8.2\/usr\/local\/bin\/php -v # Um site em cont\u00eainer docker exec php -v<\/code><\/pre>\n\n\n\n
O motivo para insistir em php -v<\/code> Ao auditar o PHP2Shell, percebe-se que todos os outros sinais s\u00e3o enganosos. A sa\u00edda da compila\u00e7\u00e3o pode reportar sucesso enquanto reutiliza uma camada em cache, um painel de controle pode mostrar um pacote como atualizado quando o worker em execu\u00e7\u00e3o n\u00e3o est\u00e1, e um cabe\u00e7alho de resposta HTTP pode ser removido por uma CDN antes mesmo de voc\u00ea v\u00ea-lo. Dois dos nossos seis sites foram reportados como \u00edntegros em suas telas de administra\u00e7\u00e3o, mesmo executando um interpretador sem patches.<\/p>\n\n\n\n
Aplicando patches no PHP2Shell no Synology em 4 etapas<\/h2>\n\n\n\n
Para um site Web Station no DSM, a corre\u00e7\u00e3o completa do PHP2Shell consiste em uma atualiza\u00e7\u00e3o do Centro de Pacotes. O pacote Synology publica atualiza\u00e7\u00f5es de seguran\u00e7a do PHP para o DSM 7.4, 7.3 e 7.2, e ap\u00f3s a atualiza\u00e7\u00e3o dos pacotes PHP, os pacotes dependentes s\u00e3o reinicializados, o que resolve o problema. O Mail Station \u00e9 a exce\u00e7\u00e3o documentada e requer uma atualiza\u00e7\u00e3o manual pr\u00f3pria.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Confira o aviso.<\/h3>\n
Abra o arquivo Synology-SA-26:14 e observe a vers\u00e3o corrigida para cada vers\u00e3o do PHP que voc\u00ea instalou. Os alvos s\u00e3o 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 e 8.4.27-0051. O PHP 7.3 n\u00e3o possui corre\u00e7\u00e3o porque est\u00e1 em fim de vida \u00fatil.<\/p>\n<\/div>\n<\/div>\n
\n
Atualize atrav\u00e9s da Central de Pacotes<\/h3>\n
No DSM, abra a Central de Pacotes e verifique os pacotes instalados. Cada pacote PHP vulner\u00e1vel mostrar\u00e1 a mensagem "Atualiza\u00e7\u00e3o dispon\u00edvel com a nova vers\u00e3o online". Clique em "Atualizar" em cada ramifica\u00e7\u00e3o do PHP listada e atualize o Calendar e o Mail Station (Synology), se os tiver instalado.<\/p>\n<\/div>\n<\/div>\n
\n
Deixe os dependentes reiniciarem<\/h3>\n
Os pacotes que dependem do PHP reiniciam automaticamente assim que o pacote PHP termina de ser atualizado, e essa reinicializa\u00e7\u00e3o \u00e9 o que coloca a corre\u00e7\u00e3o em vigor. O Mail Station \u00e9 a exce\u00e7\u00e3o e deve ser atualizado manualmente pelo Centro de Pacotes.<\/p>\n<\/div>\n<\/div>\n
\n
Verifique o interpretador em execu\u00e7\u00e3o.<\/h3>\n
N\u00e3o confie no painel de controle. Execute o comando `php -v` no caminho do pacote ou dentro do cont\u00eainer e confirme se o n\u00famero da vers\u00e3o corresponde ao aviso. Em seguida, verifique se cada host virtual do Web Station est\u00e1 vinculado a um perfil que voc\u00ea realmente atualizou.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"O
O Centro de Pacotes oferece o PHP 8.2.35-0171, a vers\u00e3o mencionada no aviso.<\/figcaption><\/figure>\n\n\n\n
A captura de tela acima foi feita em uma de nossas m\u00e1quinas na manh\u00e3 seguinte ao aviso do PHP2Shell. Observe que o painel "Novidades" indica a vers\u00e3o upstream diretamente, permitindo que voc\u00ea compare o sufixo de compila\u00e7\u00e3o Synology com a vers\u00e3o do PHP sem precisar adivinhar. O Calendar Synology aparece na mesma lista de atualiza\u00e7\u00f5es na vers\u00e3o 3.0.4-21435, que \u00e9 exatamente a vers\u00e3o recomendada no aviso.<\/p>\n\n\n\n
\"Synology
A caixa de di\u00e1logo de atualiza\u00e7\u00e3o menciona o PHP 8.2.35-0171, publicado pela Synology Inc.<\/figcaption><\/figure>\n\n\n\n
Uma armadilha do PHP2Shell que vale a pena mencionar para usu\u00e1rios do Web Station: uma m\u00e1quina DSM pode ter v\u00e1rias vers\u00f5es do PHP instaladas simultaneamente, e cada host virtual est\u00e1 vinculado a um perfil. Atualizar o perfil padr\u00e3o n\u00e3o resolve o problema de um site vinculado a uma vers\u00e3o diferente. Primeiro, liste os perfis, atualize todos eles e, em seguida, verifique a vincula\u00e7\u00e3o de cada site em Servi\u00e7os Web.<\/p>\n\n\n\n
Quais pacotes DSM s\u00e3o afetados?<\/h2>\n\n\n\n
A declara\u00e7\u00e3o Synology no PHP2Shell \u00e9 mais restrita do que o p\u00e2nico sugeria. Apenas sistemas que executam determinados pacotes dependentes do PHP s\u00e3o afetados, e o Synology Drive explicitamente n\u00e3o est\u00e1 entre eles. O IDrive est\u00e1 na lista, mas \u00e9 um software de terceiros.<\/p>\n\n\n\n