Security audit

MTProto 2.0

Security checks across malware telemetry and agentic risk

Overview

This is a documentation-only MTProto guide, but it contains materially unsafe and contradictory cryptography guidance that could mislead production implementations.

Install only as a non-authoritative learning aid. Do not copy the crypto or parser examples into production; cross-check every MTProto detail against Telegram’s official documentation and audited implementations, especially Auth Key ID derivation, AES-IGE authentication assumptions, random generation, padding, message-key verification, and bounds checks.

SkillSpector

By NVIDIA

Vulnerability Patterns

MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (7)

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The documentation states that IGE provides integrity checking through error propagation and later labels its integrity as partial, but the provided construction is still unauthenticated encryption and does not provide cryptographic integrity or authenticity. Readers implementing this as written may accept tampered ciphertexts as valid, enabling message modification, malleability abuse, and unsafe protocol designs in a security-sensitive Telegram/MTProto context.

Intent-Code Divergence

Low

Confidence: 90% confidence
Finding: The documentation gives contradictory statements about IGE error behavior, first claiming corruption garbles all subsequent blocks and then claiming decryption resumes correctly after two blocks. This inconsistency can mislead implementers about failure handling, tamper effects, and test expectations, increasing the chance of incorrect security assumptions in protocol implementations.

Intent-Code Divergence

High

Confidence: 99% confidence
Finding: The example code gives contradictory and incorrect guidance for deriving the MTProto Auth Key ID: it comments that SHA1[12:16] is 4 bytes, then presents padding/partial copying into an 8-byte field as 'CORRECT'. Implementers following this will generate nonstandard key identifiers, causing protocol incompatibility and potentially misbinding encrypted messages to the wrong auth key lookup path. In a cryptographic protocol implementation guide, such ambiguity is especially dangerous because developers often copy sample code directly.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: Documenting a SHA256-based Auth Key ID as an 'alternative' conflicts with the surrounding MTProto definition and invites incompatible implementations. While this is less likely to create a direct memory-safety flaw, it can break interoperability, cause authentication/key lookup failures, and lead developers to ship protocol forks that silently fail or mishandle encrypted traffic. Because this skill is specifically for backend MTProto implementation, contradictory crypto guidance is more dangerous than it would be in a purely historical or educational document.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The documentation gives an inconsistent description of TL string length encoding: it states a 1-3 byte length, while the sample implementation actually uses either 1 byte or 4 bytes total for the length prefix (0xfe plus 3 little-endian bytes). In a protocol implementation guide, this kind of mismatch can cause developers to build incompatible parsers/serializers, leading to malformed message handling, interoperability failures, and potentially unsafe decoder logic when implementations make incorrect assumptions about framing.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: The decode example performs fixed-offset reads such as slicing data[offset:offset+8] and calling decodeString on subsequent offsets without first verifying that enough bytes remain. If copied into production code, malformed or attacker-controlled network input can trigger out-of-bounds panics or unsafe parsing behavior, creating a denial-of-service risk in Telegram-compatible backends or protocol handlers exposed to untrusted peers.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: This file is an implementation guide for a cryptographic protocol, so omissions and unsafe examples are especially dangerous because developers may copy them directly into production. The guide uses unauthenticated encryption, shows all-zero test key/IV material, provides padding helpers without robust validation, and does not prominently warn that these examples are protocol-specific and unsafe as generic secure messaging patterns, which can lead to broken confidentiality/integrity guarantees if reused outside the exact MTProto design.

VirusTotal

66/66 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

No suspicious patterns detected.