O Ticket Jira Que Leu o Servidor

Um ticket do Jira deve descrever o trabalho. Não deve ler seu servidor.

No dia 12 de agosto, o NVD publicou o CVE-2026-73498, cujo aviso confirma um agente fazendo exatamente isso. O agente leu instruções em um ticket do Jira, chamado de ferramenta de upload MCP, abriu /proc/self/environ e anexou o resultado ao Confluence. Esse arquivo pode conter credenciais ativas. A interação inicial foi uma revisão de ticket comum.

Nenhum malware, shell ou autenticação quebrada foi necessário. A exploração usou uma chamada de ferramenta válida e a identidade já atribuída ao servidor MCP.

Isso foi uma prova de conceito confirmada, não uma violação de produção relatada. Essa distinção é importante, mas também a parte desconfortável: uma revisão convencional poderia aprovar cada peça visível e ainda assim perder a transferência de autoridade.

A chamada era válida. A autoridade não era

MCP Atlassian é um servidor que conecta agentes ao Confluence e ao Jira. Antes da versão 0.22.0, sua ferramenta de upload aceitava um caminho fornecido pelo cliente e o abria sem a verificação de caminho seguro já utilizada pelo caminho de download.

O esquema dizia que file_path era uma string. Era. A autenticação poderia passar. A ferramenta era permitida. Nenhuma dessas verificações respondeu se o texto lido do Jira deveria ser capaz de gastar a autoridade do sistema de arquivos do servidor.

O ticket forneceu a intenção, o tempo de execução forneceu a permissão e o Confluence tornou o resultado durável.

Isso é mais do que um bug de validação de caminho. É uma revisão de autorização que parou na assinatura da função.

Quatro perguntas que o esquema não pode responder

A virada é simples: pare de revisar a declaração da ferramenta como o limite. Para cada chamada consequente, rastreie quatro coisas:

1. Origem: O que causou a chamada? Um pedido de usuário, conteúdo do Jira, texto recuperado ou outro agente?
2. Autoridade: De quem é a identidade que paga por isso? Um token de usuário, conta de serviço ou credencial delegada?
3. Consequência: O que pode sair ou mudar? Um arquivo, registro persistente, sistema externo ou destino de rede?
4. Tempo: A mesma política é executada em novas tentativas, pollers e trabalhos em segundo plano?

Um esquema descreve a forma da chamada. Não concede permissão.

Três avisos, quatro respostas faltando

Quando eu reviso um grande plano de ferramentas, não pergunto apenas se a ferramenta está autenticada. Eu rastreio a origem, autoridade, consequência e caminho do tempo até que eu possa apontar a negação exata.

A prova de conceito da Atlassian falhou nas três primeiras perguntas. O conteúdo não confiável do Jira causou a chamada. A identidade do servidor poderia ler o ambiente do processo. A consequência foi um arquivo portador de credenciais copiado em um anexo visível para o inquilino.

Dynatrace MCP é um servidor que expõe operações do Dynatrace como ferramentas de agente. Cinco ferramentas de escrita solicitaram aprovação humana. create_dynatrace_notebook não. Antes da versão 1.8.7, acessar essa ferramenta era suficiente para criar um caderno persistente sem o consentimento do operador. O aviso classifica isso como BAIXO. A lição durável não é a pontuação. É que a autenticação respondeu quem chamou, enquanto nenhum controle respondeu quem aprovou a escrita.

FrontMCP é uma estrutura que transforma definições OpenAPI em ferramentas MCP. Seu carregamento inicial de URL usou uma proteção SSRF. Seu poller de fundo opcional usou fetch() bruto. Antes da versão 1.5.6, uma URL de especificação influenciável por atacantes poderia fazer com que esse poller alcançasse loopback, redes privadas ou endpoints de metadados em nuvem. A pollagem estava desativada por padrão. A primeira solicitação tinha política. A solicitação posterior não tinha.

Os produtos e a gravidade diferem, mas o erro de revisão é o mesmo: a política cobriu a chamada declarada, não cada lugar onde sua autoridade se tornou ação.

Coloque a proteção onde a consequência acontece

INACEITÁVEL

def upload(file_path):
    return open(file_path, "rb")

async def create_notebook(content):
    return await write(content)

async def poll(url):
    return await fetch(url)

ACEITÁVEL

def upload(file_path, allowed_root):
    path = Path(file_path).resolve()
    path.relative_to(allowed_root)
    return path.open("rb")

async def create_notebook(content, approve):
    if not await approve(content):
        raise PermissionError("aprovação necessária")
    return await write(content)

async def poll(url):
    return await fetch(url)