TimThumb morreu! Como lidar com imagens no WordPress (guia 2026)

Se é um veterano do WordPress, certamente lembra-se do TimThumb. Era um pequeno script PHP encontrado em quase todos os “temas premium” por volta de 2010. Ele permitia cortar e redimensionar imagens em tempo real facilmente.

Em agosto de 2011, foi descoberta nele uma vulnerabilidade crítica Zero-Day que permitia a atacantes carregar e executar código PHP nos servidores com o script. Isso marcou o fim da era dos “scripts simples”.

Hoje, em 2026, o WordPress possui um poderoso motor de gestão de media. Se ainda vê timthumb.php no seu tema, apague-o imediatamente. Este guia mostra como fazer isso profissionalmente.

#Porque é que o TimThumb era inseguro

O TimThumb funcionava em tempo real: pegava numa imagem de um URL, processava-a e guardava-a em cache. Os problemas eram muitos e graves:

1. Segurança: Permitia execução remota de código (RCE). Mark Maunder tornou a vulnerabilidade pública a 1 de agosto de 2011, depois de o seu próprio blogue ter sido atacado. O script só comparava parcialmente o nome do anfitrião com a sua lista branca de domínios, por isso um atacante podia fazê-lo descarregar um ficheiro PHP para a pasta de cache e depois executar esse ficheiro com um pedido direto. Isso dava acesso total ao site e potencialmente ao servidor inteiro. Maunder recomendava ainda procurar na pasta do WordPress a função base64_decode e cadeias codificadas longas, o rasto típico de código injetado.

2. Desempenho: Sobrecarregava o servidor PHP a cada novo pedido de imagem. Sempre que um visitante abria uma página com imagens do TimThumb, o servidor tinha de executar PHP, verificar a cache, processar a imagem se não existisse e enviá-la. Em sites com muito tráfego, isso significava muitas execuções PHP adicionais a consumir CPU e memória. O processamento de imagens exige muitos recursos, e fazê-lo ao vivo através de PHP era muito ineficiente em comparação com servir ficheiros estáticos já gerados.

3. Sem integração: Não reconhecia a biblioteca de media do WordPress. O TimThumb funcionava totalmente fora do ecossistema WordPress. Não usava hooks nem funções do core, não registava as imagens processadas na base de dados e não beneficiava das melhorias que o WordPress ia fazendo na gestão de media. As imagens do TimThumb não apareciam na biblioteca de media, não podiam ser geridas no painel e não tinham texto alternativo, descrições nem créditos de imagem.

#Cronologia das vulnerabilidades do TimThumb

A história do script cabe em quatro datas, e todas estão documentadas em fontes primárias:

O identificador CVE-2011-4106 só foi publicado na NVD mais tarde, em outubro de 2013, mas a descrição oficial diz que a falha foi explorada em agosto de 2011. Maunder estimou a escala de forma indireta na altura: o Google devolvia mais de 39 milhões de resultados para o nome do script. O seu diagnóstico de fundo continua válido para qualquer redimensionador metido dentro de um tema:

“O timthumb.php é inseguro por natureza, porque depende de poder escrever ficheiros numa pasta a que os visitantes do seu site têm acesso.”

Mark Maunder, 1 de agosto de 2011, tradução própria

A correção de 2011 fechou aquele buraco concreto, mas não mudou o desenho. Três anos depois chegou a falha do WebShot, que passava metacaracteres de shell do parâmetro src para um comando do sistema. Gillbanks escreveu no anúncio de 2014 que mal tinha tocado no código durante anos e que quem continuasse a usar o TimThumb o fazia por sua conta e risco. Um tema que ainda inclui o ficheiro depende, portanto, de código sem manutenção há mais de uma década.

#Como registar tamanhos nativos com add_image_size

O WordPress tem a função add_image_size() há anos. Ela permite definir formatos que o sistema gera automaticamente durante o upload. É a forma mais eficiente e segura de gerir os diferentes tamanhos de imagem de que o seu tema precisa.

#Registar tamanhos no functions.php

function wppoland_setup_theme() {
    // Ativar suporte para imagens destacadas
    add_theme_support( 'post-thumbnails' );

    // Tamanhos padrão (corte suave: mantém as proporções)
    add_image_size( 'blog-list', 800, 400 );

    // Corte rígido (corta o excesso)
    // O WordPress corta exatamente o centro da imagem
    add_image_size( 'team-member', 300, 300, true );

    // Corte com posicionamento (ex.: a partir de cima, da esquerda)
    add_image_size( 'hero-banner', 1920, 600, ['center', 'top'] );
}
add_action( 'after_setup_theme', 'wppoland_setup_theme' );

Quando define tamanhos próprios com add_image_size(), o WordPress gera todas as variantes no momento do upload. O trabalho pesado acontece uma vez, no carregamento do ficheiro, e não em cada visualização da página. Por isso esta abordagem é muito mais rápida do que qualquer redimensionamento em tempo real.

Vale a pena conhecer os três modos de corte. O corte suave (soft crop) é o comportamento por omissão quando não indica o parâmetro de corte. O WordPress reduz a imagem para caber nas dimensões indicadas, mantendo a proporção original, por isso uma das dimensões pode ficar menor do que a indicada. O corte rígido (hard crop), ativado com true como terceiro parâmetro, força exatamente as dimensões indicadas e corta as margens que sobram. O corte posicionado define a partir de que ponto da imagem se faz o corte, o que ajuda em banners onde o motivo principal costuma estar em cima.

#Mostrar o tamanho no template (single.php)

if ( has_post_thumbnail() ) {
    the_post_thumbnail( 'hero-banner', ['class' => 'img-fluid'] );
}

Se já tem o ID do anexo, wp_get_attachment_image() faz o mesmo fora do loop:

echo wp_get_attachment_image( $attachment_id, 'blog-list' );

Vantagem: As imagens são geradas uma vez (no upload). São servidas como ficheiros estáticos prontos. Zero carga de PHP na apresentação. Os ficheiros estáticos também são fáceis de pôr em cache, tanto no servidor como na CDN.

#Como regenerar miniaturas com WP-CLI

Quando acrescenta novos tamanhos a um tema existente, as imagens já carregadas não têm as novas variantes. É preciso regenerar as miniaturas, e a forma mais eficiente é o WP-CLI:

wp media regenerate --yes

Para bibliotecas grandes, a documentação de wp media regenerate tem opções que limitam o trabalho: --only-missing gera só os tamanhos em falta, --image_size=<nome> regenera um único tamanho e --skip-delete mantém as miniaturas antigas caso alguém as ligue a partir de fora:

wp media regenerate --only-missing --yes
wp media regenerate --image_size=hero-banner --yes

#Que tamanhos de imagem o WordPress gera por omissão

Antes de registar tamanhos próprios, convém saber quantos ficheiros o core já cria em cada upload. Os valores por omissão das opções no esquema do WordPress são:

Os dois últimos são acrescentados pela função interna _wp_add_additional_image_sizes(), e um comentário no código do core desaconselha alterá-los porque o nome reflete as dimensões. Cada add_image_size() do seu tema soma-se a esta lista, por isso um único upload produz facilmente dez ficheiros ou mais.

O WordPress 5.3 introduziu também um limiar para imagens grandes. Se o original ultrapassar 2560 píxeis de largura ou altura, o core cria uma cópia reduzida com o sufixo -scaled e usa-a como tamanho “full”; o original é mantido e o seu nome fica nos metadados do anexo (original_image). O valor altera-se ou desativa-se com o filtro big_image_size_threshold:

// Subir o limiar para 4000 px
add_filter( 'big_image_size_threshold', fn() => 4000 );

// Desativá-lo por completo
add_filter( 'big_image_size_threshold', '__return_false' );

Para o srcset existe um limite paralelo: o filtro max_srcset_image_width exclui do conjunto, no código atual do core, os candidatos com mais de 2048 píxeis de largura. Se um tema precisa de candidatos maiores para ecrãs de alta densidade, é esse o filtro a ajustar, e não um script de redimensionamento.

#Como redimensionar imagens WordPress com uma CDN

Os tamanhos nativos têm uma desvantagem: se mudar de tema, tem de regenerar as miniaturas (por exemplo, com o plugin Regenerate Thumbnails), o que demora imenso numa biblioteca de 100 GB.

Em 2026, os servidores são rápidos e as CDNs são baratas. Usamos muitas vezes uma abordagem híbrida ou serviços externos que processam as imagens na periferia da rede, perto do utilizador.

#Redimensionar com parâmetros de URL na CDN

Em vez de sobrecarregar o seu servidor PHP, use parâmetros de URL e deixe a CDN tratar do processamento. A sintaxe exata depende do fornecedor; de forma esquemática:

<img src="https://oseusite.pt/wp-content/uploads/imagem.jpg?width=400&height=300&format=avif">

O original fica no seu servidor, e a CDN redimensiona-o, converte o formato e entrega a versão otimizada. Não precisa de um script PHP no seu servidor para isso.

As vantagens são claras. Primeiro, não precisa de regenerar miniaturas para tamanhos novos, porque a CDN gera qualquer tamanho a pedido. Segundo, a conversão de formato é automática: a CDN pode servir AVIF aos navegadores que o suportam e WebP como alternativa. Terceiro, cada transformação fica na cache da periferia, por isso o custo de a processar paga-se uma só vez.

#Cloudflare Image Resizing

Na Cloudflare, a transformação pede-se diretamente no URL, no formato https://<zona>/cdn-cgi/image/<opções>/<imagem-original>, por exemplo /cdn-cgi/image/width=400,format=auto/wp-content/uploads/2026/10/foto.jpg. Segundo a documentação da Cloudflare, isto funciona nas zonas com as transformações ativas, e format=auto entrega o formato mais eficiente que o navegador suporta. Não é preciso um Worker para isto; os Workers servem quando quer regras próprias, por exemplo reescrever automaticamente os URL de /wp-content/uploads/.

#Como usar srcset e sizes nas imagens WordPress

O WordPress gera automaticamente o atributo srcset para as suas imagens, permitindo ao navegador escolher o tamanho adequado ao dispositivo (telemóvel vs. ecrã 4K). A funcionalidade chegou no WordPress 4.4 e tem sido melhorada desde então.

<!-- O WordPress gera isto automaticamente: -->
<img src="imagem-800x400.jpg"
     srcset="imagem-300x150.jpg 300w,
             imagem-800x400.jpg 800w,
             imagem-1024x512.jpg 1024w"
     sizes="(max-width: 600px) 100vw, 800px">

O atributo srcset lista todas as variantes disponíveis da imagem com a largura em píxeis. O navegador combina essa informação com o atributo sizes e escolhe o ficheiro que melhor se adapta ao tamanho do ecrã, à densidade de píxeis e à largura do viewport.

Segundo a nota de desenvolvimento do WordPress 4.4, o valor sizes por omissão equivale a (max-width: {largura}px) 100vw, {largura}px, e se o HTML do conteúdo já tiver srcset ou sizes, o WordPress não lhes toca. O seu trabalho como programador é definir corretamente sizes com o filtro wp_calculate_image_sizes. Com ele descreve como a imagem é apresentada nos breakpoints do layout, para o navegador escolher da melhor forma:

add_filter( 'wp_calculate_image_sizes', function( $sizes, $size, $image_src, $image_meta ) {
    // Para imagens dentro de artigos
    if ( is_singular() ) {
        return '(max-width: 768px) 100vw, (max-width: 1200px) 75vw, 800px';
    }
    return $sizes;
}, 10, 4 );

#Que atributos de carregamento o WordPress acrescenta às imagens

Desde o WordPress 5.5, o atributo loading="lazy" é acrescentado automaticamente às imagens. As imagens fora da primeira vista só são descarregadas quando o utilizador faz scroll até elas, o que acelera o primeiro carregamento da página.

O WordPress 6.1 acrescentou a wp_get_attachment_image() o atributo decoding="async", que deixa o navegador descodificar as imagens sem bloquear a renderização. Desde o WordPress 6.3, os três atributos são decididos por uma só função, wp_get_loading_optimization_attributes(). Ela marca com fetchpriority="high" a primeira imagem suficientemente grande (o limiar por omissão é de 50 000 píxeis de área, filtro wp_min_priority_img_pixels) e não lhe acrescenta loading="lazy", porque um elemento nunca deve ter as duas coisas. Se a sua imagem LCP vem de um bloco ou de um fundo CSS que essa função não vê, marque-a manualmente.

#Como otimizar imagens WordPress com WebP e AVIF

Em 2026, JPG e PNG são relíquias para fotografias. O WordPress suporta nativamente WebP (desde a versão 5.8) e AVIF (desde a versão 6.5), desde que a biblioteca de imagens do servidor (Imagick ou GD) suporte o formato. O ecrã Ferramentas > Saúde do site, separador Informação, secção de tratamento de multimédia, mostra que formatos o seu servidor suporta.

Não precisa de plugins para isso. Basta fazer upload de um ficheiro AVIF, e o WordPress lida com ele. Ou use o plugin Modern Image Formats da equipa de desempenho do WordPress, que gera os subtamanhos dos JPEG carregados em AVIF (ou em WebP, se o servidor não suportar AVIF) e mantém o original.

#Quanto pesam WebP e AVIF face ao JPG

Os números oficiais do core são estes:

• WebP: em média cerca de 30% mais leve do que o equivalente JPEG ou PNG, segundo a nota do WordPress 5.8.
• AVIF: até 50% mais leve do que JPEG com a mesma qualidade, segundo a nota do WordPress 6.5.

O AVIF comprime geralmente melhor do que o WebP, sobretudo em fotografias com gradientes suaves. O WebP tem um suporte um pouco mais amplo em navegadores antigos, por isso uma estratégia comum é servir AVIF como primeira opção e WebP como alternativa.

#Como usar o elemento picture com AVIF e WebP

Para controlo total sobre os formatos servidos, pode usar o elemento HTML <picture>:

<picture>
    <source srcset="imagem.avif" type="image/avif">
    <source srcset="imagem.webp" type="image/webp">
    <img src="imagem.jpg" alt="Descrição da imagem">
</picture>

Na maioria dos casos, porém, deixar a negociação de formato ao WordPress e à CDN é a solução mais prática e fácil de manter.

#Como alterar a qualidade e o formato de saída no WordPress

Cada subtamanho que o WordPress gera passa pela classe WP_Image_Editor, e dois filtros controlam o resultado.

O primeiro é a qualidade. No código-fonte atual da classe, a qualidade por omissão é 82 para JPEG e 86 para WebP; os restantes formatos ficam com 82. O filtro wp_editor_set_quality recebe a qualidade e o tipo MIME, por isso pode ajustar cada formato em separado. Nos JPEG, o core aplica depois o filtro antigo jpeg_quality, que tem a última palavra se algum plugin o usar:

add_filter( 'wp_editor_set_quality', function( $quality, $mime_type ) {
    if ( 'image/avif' === $mime_type ) {
        return 70;
    }
    return $quality;
}, 10, 2 );

O segundo é o formato de saída. O filtro image_editor_output_format associa a cada tipo MIME de entrada o formato em que os subtamanhos são guardados. A nota do WordPress 6.5 usa exatamente este exemplo para que os JPEG carregados produzam subtamanhos AVIF:

add_filter( 'image_editor_output_format', function( $formats ) {
    $formats['image/jpeg'] = 'image/avif';
    return $formats;
} );

Desde o WordPress 6.7, o core usa o mesmo mecanismo por omissão para as fotos HEIC dos iPhone: se o servidor as conseguir ler, converte-as para JPEG no upload. A mudança de formato só afeta imagens novas ou regeneradas, por isso depois de ativar o filtro é preciso correr wp media regenerate.

#Como remover TimThumb do WordPress com segurança

Se herdou um projeto antigo, remova o TimThumb de forma segura e completa:

1. Analise: Procure na pasta wp-content os ficheiros timthumb.php ou thumb.php. Procure também pastas de cache associadas.
2. Apague: Apague o ficheiro e a pasta de cache associada (normalmente uma pasta cache dentro da pasta do tema).
3. Corrija: Encontre no código os sítios onde era chamado:

   // CÓDIGO ANTIGO (MAU)
   <img src="<?php echo get_template_directory_uri(); ?>/timthumb.php?src=..." />
   
   // SUBSTITUIR POR (BOM)
   <?php the_post_thumbnail( 'meu-tamanho' ); ?>

4. Regenere: Instale o WP-CLI e execute wp media regenerate.
5. Verifique: Depois da migração, percorra todas as páginas principais do site e confirme que as imagens aparecem corretamente. Preste atenção especial às páginas de arquivo, aos widgets da barra lateral e ao rodapé, onde o TimThumb pode ter sido usado.

#Como procurar referências ao TimThumb com grep

Não basta apagar o ficheiro. Tem de encontrar todas as referências no código:

# Procurar em todos os ficheiros PHP do tema
grep -r "timthumb" wp-content/themes/o-seu-tema/
grep -r "thumb.php" wp-content/themes/o-seu-tema/

# Procurar também em plugins próprios
grep -r "timthumb" wp-content/plugins/

# Rasto de código injetado que Maunder recomendava verificar
grep -rl "base64_decode" wp-content/

Cada referência encontrada deve ser substituída pela função nativa equivalente do WordPress. Na maioria dos casos, isso significa usar the_post_thumbnail() ou wp_get_attachment_image() com o tamanho certo. Um resultado de base64_decode não prova uma infeção, porque alguns plugins legítimos usam a função, mas cada ocorrência num tema merece leitura.

Veja também a nossa auditoria de segurança WordPress.

#Como medir o desempenho das imagens no WordPress

Depois de passar do TimThumb para os métodos nativos, confirme que o desempenho melhorou. Use o Google PageSpeed Insights, o Lighthouse e o WebPageTest para medir os tempos de carregamento antes e depois da migração.

#Que métricas de imagem medir: LCP, CLS e TTFB

• Largest Contentful Paint (LCP): A imagem principal costuma ser o elemento LCP. Com tamanhos nativos pré-gerados, fetchpriority="high" e uma CDN, o LCP deve melhorar.
• Cumulative Layout Shift (CLS): Garanta que todas as imagens têm width e height definidos para evitar saltos de layout durante o carregamento. As funções de anexos do WordPress acrescentam-nos sozinhas.
• Time to First Byte (TTFB) das imagens: Sem redimensionamento em PHP, a resposta de cada imagem já não espera pelo PHP nem pelo GD.

#Configuração do servidor para imagens WordPress

Para um bom desempenho de imagens no WordPress em 2026, a configuração recomendada inclui:

• Cache do navegador com cabeçalhos Cache-Control longos para ficheiros de imagem (pelo menos um ano)
• CDN com transformações de imagem e conversão automática de formato
• Preload da imagem LCP com <link rel="preload"> quando a imagem não aparece cedo no HTML

#Como gerir imagens no WordPress sem TimThumb

A história do TimThumb é uma lição de humildade. Conveniência (redimensionamento em tempo real) não pode estar acima da segurança. Em 2026, temos add_image_size() nativo, srcset responsivo e CDNs a processar imagens na nuvem. Não há razão para voltar a soluções de há 15 anos atrás.

A gestão moderna de imagens no WordPress assenta em três pilares: geração de tamanhos no upload com add_image_size(), entrega responsiva com srcset e sizes, e otimização de formato com WebP/AVIF. Combinados com uma CDN para a entrega, dão imagens rápidas, seguras e fáceis de manter em qualquer site WordPress.

Veja os nossos serviços de otimização de velocidade WordPress.