Senha no app do Applebee's: o log que falta custa mais

O app do Applebee's, instalado em mais de um milhão de celulares Android, saiu de fábrica com a senha de um banco de dados de clientes dentro dele. Não vazou — foi distribuída, compilada no arquivo que cada instalação baixou. A Dine Brands Global, a dona da marca, listada na Bolsa de Nova York, diz que o time de segurança não encontrou nenhuma evidência de que alguém tenha usado a senha. Perguntada se tem logs de acesso capazes de sustentar isso — ou se tem log algum —, a empresa não respondeu. A senha no código é a metade barata da falha. A segunda frase é a metade caríssima.

O que isso custa, e quem consegue te responder

O banco guardava os campos que a pessoa sente na pele: nome, e-mail, data de nascimento, telefone, CEP, condição de veterano e o endereço IP do último login. Esse último é o mais subestimado — IP com horário é localização aproximada e rotina aproximada.

Então, para quem já pediu pelo app, a resposta honesta para "minha data de nascimento foi lida?" é que ninguém até agora disse que consegue responder. "Nenhuma evidência de acesso não autorizado" é declaração da própria Dine Brands, dada por um porta-voz não identificado, e o mesmo porta-voz se recusou a dizer se existem logs para sustentá-la. Um laudo de "nenhuma evidência" vale exatamente o que valia a coisa examinada.

Reportagem do TechCrunch de 30 de outubro de 2026: a declaração e a pergunta que ela não sustenta.

Vale separar os dois tipos de afirmação, porque o resto da cobertura mistura. Conferido em fonte primária: a página do app no Google Play, a faixa de instalações, a data da última versão, as declarações de dados feitas pelo próprio desenvolvedor, as definições e os prazos da SEC e o histórico de arquivamentos da Dine Brands. Relatado por parte interessada e não verificável de fora: que não houve acesso não autorizado, que a falha já foi corrigida, que a credencial também permitiria alterar registros e não só lê-los (avaliação do pesquisador) e o tamanho do programa de fidelidade. Não testamos o app — e você também não deve.

A postura já era pública antes da reportagem

Nada disso estava escondido. O painel "Segurança dos dados" do próprio app no Google Play — um formulário que o Google diz ser preenchido pelo desenvolvedor — já avisava a cada uma daquelas instalações que o app pode compartilhar localização, informações pessoais e informações financeiras com terceiros, e que "os dados não são criptografados".

Seção "Segurança dos dados" do app do Applebee's no Google Play, preenchida pelo desenvolvedor. Capturada em 31 de outubro de 2026.

Leia o rótulo com precisão, porque ele é mais estreito do que parece. A documentação do Play Console pede que o desenvolvedor confirme se todos os dados coletados pelo app são criptografados em trânsito, e diz que só é possível declarar a criptografia se ela cobrir todos os caminhos — incluindo cada SDK e biblioteca que manda dados para fora do aparelho. "Os dados não são criptografados" significa, portanto, que o desenvolvedor não afirmou que todos esses caminhos são criptografados. Não estabelece que alguma requisição específica trafegue em claro, e ninguém publicou captura de tráfego mostrando isso.

O que não muda o essencial: a reportagem não revelou a postura de segurança da empresa. Ela colocou preço nela.

Segredo em app publicado não está guardado, está distribuído

Credencial em configuração de servidor está guardada: uma cópia, num lugar que você controla, revogável em um segundo. Credencial compilada num app móvel está publicada. O número do próprio Google Play fala de mais de 1 milhão de instalações, e cada cópia é um arquivo que um atacante abre no notebook dele — o TechCrunch diz ter confirmado o achado baixando e descompilando o app.

Isso muda o que significa corrigir. Não se recolhe uma string de um milhão de celulares. A última atualização na página do Play é de 14 de outubro de 2026, antes do aviso do pesquisador e antes da publicação; a data do Play pode atrasar em relação a um lançamento gradual, então trate isso como observação, não como conclusão sobre o que a empresa fez internamente. Se essa data se confirma, o conserto não chegou aos celulares como atualização — o que deixa só a rotação no servidor. Rotação revoga a credencial no milhão de cópias de uma vez. Uma versão nova só alcança quem atualiza.

Por que o log que não existe é a metade caríssima

A Dine Brands é companhia aberta: CIK 0000049754, ticker DIN. Desde dezembro de 2023 está sujeita à regra de divulgação cibernética da SEC — e a regra gira em torno de uma palavra.

O 17 CFR 229.106(a) define incidente de cibersegurança como "uma ocorrência não autorizada" nos sistemas da companhia que compromete confidencialidade, integridade ou disponibilidade. Ameaça de cibersegurança é "qualquer ocorrência não autorizada potencial". O Item 1.05 do Form 8-K adota essas definições. Qual das duas palavras se aplica a uma senha de banco distribuída para um milhão de celulares depende de um único fato: se alguém a usou. Log de acesso é a única coisa que responde isso.

17 CFR 229.106(a) — as definições que o Item 1.05 adota. Consultado em 31 de outubro de 2026.

E a pergunta vem com cronômetro. A Instrução 1 do Item 1.05 exige que a determinação de materialidade "seja feita sem demora injustificada após a descoberta do incidente", e a Instrução Geral B.1 dá quatro dias úteis para arquivar depois que a companhia determina ter sofrido um incidente material. Os quatro dias contam da determinação, não da descoberta — ou seja, "a investigação segue em andamento" não é botão de pausa. A determinação é justamente o que não pode ser adiado sem justificativa.

Instruções do Item 1.05 do Form 8-K, da norma publicada pela SEC em 2023.

Até hoje, 31 de outubro de 2026, nenhum Item 1.05 aparece no histórico de 8-K da Dine Brands no EDGAR — em nenhum dos 127 arquivamentos 8-K e 8-K/A desde janeiro de 2018. Isso é registro do que foi arquivado com um dia de história, não acusação de atraso: a obrigação nasce da determinação, não da descoberta.

O problema real é mais estreito e pior que prazo perdido. Uma empresa que não sabe dizer se tem logs não consegue fazer a determinação na qual o cronômetro está preso. A credencial era uma linha para rotacionar. O log que ninguém ligou em julho não se produz em outubro.

Três decisões mais baratas que a divulgação

1. Nenhuma credencial de vida longa dentro do binário do cliente. O app autentica a pessoa e recebe um token de curta duração, por usuário, com escopo, emitido no seu servidor. Aí o pior caso de uma versão descompilada é um token expirado, não um banco de dados. Já escrevemos sobre essa falha em stacks de agentes: é o mesmo erro com embalagem diferente.
2. Log de acesso, com retenção de verdade, em todo repositório com dado pessoal de cliente. "Nenhuma evidência de acesso não autorizado" só é um achado se havia o que examinar; sem isso é uma frase. Para companhia aberta, é também o que torna a determinação do Item 1.05 respondível dentro de um prazo. E é a mesma pergunta com que começa qualquer comunicação de incidente à ANPD. Cobrimos a lacuna idêntica numa stack de inferência, e o final foi o mesmo: sem log, sem resposta.
3. Um canal publicado para te avisarem. Os únicos contatos na página do Applebee's no Play são uma caixa de relacionamento com o cliente e um endereço de desenvolvedor. Não conseguimos verificar se applebees.com ou dinebrands.com publicam arquivo de contato de segurança — os dois hosts recusam requisição automatizada —, então o que se pode dizer é que não há endereço de segurança publicado onde um pesquisador olha primeiro. O deste caso acabou encaminhando o relato por meio de um jornalista. Um security.txt e uma caixa monitorada são uma tarde de trabalho.

Se o seu app foi construído rápido — por agência, por terceirizado ou por um agente de código num fim de semana —, assuma que existe uma credencial de servidor compilada dentro dele até alguém descompilar a sua própria versão e conferir. Boa parte de levar software feito com IA para produção é exatamente isso.

Pontos principais

• Segredo dentro de app móvel está publicado em cada instalação, então a correção real é rotacionar no servidor, não lançar uma atualização.
• "Nenhuma evidência de acesso não autorizado" é uma afirmação sobre a sua evidência, não sobre o seu atacante. Sem log de acesso, não carrega informação.
• A regra cibernética da SEC separa incidente de ameaça pelo fato de o acesso ter ocorrido ou não, e põe cronômetro na determinação — as duas coisas dependem de log.
• Token curto com escopo, log de acesso retido e contato de segurança publicado custam menos que um único ciclo de divulgação.