Security audit

MTProto 2.0

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only MTProto skill, but its security-critical examples contain multiple contradictory or incorrect protocol and cryptography instructions that could mislead implementation work.

Treat this skill as review-required before installation. It appears to be documentation-only and not locally dangerous by itself, but do not let an agent copy its MTProto crypto or parsing examples into production code without checking the official Telegram specification, known-good libraries, and independent cryptographic review.

A.I.G

Vulnerability Patterns

Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally

Findings (6)

T09 · Insecure Skill Coding Practices

Error

Location: references/encryption.md:94
Finding: Broken MTProto 2.0 AES key and IV derivation
Content: View full analysis
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Error

Location: references/message-format.md:23
Finding: Invalid Auth Key ID and message-key algorithms
Content: View full analysis
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Error

Location: references/handshake.md:156
Finding: Incorrect MTProto handshake authentication and RSA construction
Content: View full analysis
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Error

Location: references/handshake.md:170
Finding: Missing validation of the remote Diffie-Hellman public value
Content: View full analysis
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Warning

Location: references/encryption.md:181
Finding: Insecure padding generation and incorrect encrypted-message framing
Content: View full analysis
len(plaintext) { return nil, nil, errors.New("invalid length") } bodyWithPadding := plaintext[32 : 32+length] // Strip padding (find actual body length from TL) body := stripPadding(bodyWithPadding) ``` ### Technical Analysis The examples do not qualify `rand`, and elsewhere use `rand.Intn`, which commonly refers to `math/rand`. Such randomness is unsuitable for cryptographic padding and conflicts with the project's own security notice. The framing instructions also conflate message-data length, padding length, and four-byte word counts. The shown constructor includes padding in the length field, while the parser then attempts to infer the body boundary by stripping padding from that combined region. This can create disagreement about authenticated body boundaries and produces packets that are i ...[truncated 856 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Warning

Location: references/tl-language.md:191
Finding: Unchecked TL decoder slices allow remote process crashes
Content: View full analysis
Remediation: View remediation

SkillSpector

Vulnerability Patterns

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

Findings (10)

Intent-Code Divergence

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The documented auth_key_id derivation is wrong: it states an XOR with new_nonce, which does not match MTProto semantics and conflicts with the rest of the protocol description. A developer implementing this would derive incorrect key identifiers, leading to protocol breakage, message routing failures, and potentially incorrect trust in session state.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

High

Category: Not specified by scanner
Confidence: 99% confidence
Finding: This documentation presents an incorrect auth_key_id derivation as 'CORRECT' and mandatory, while the sample only copies 4 bytes from SHA1 and leaves the remaining 4 bytes zero or undefined. In a protocol implementation guide, this can cause incompatible or ambiguous key identifiers, failed key lookup, and broken encrypted message handling across clients/servers; because implementers are likely to copy the sample verbatim, the skill context makes the issue more dangerous than a generic code snippet.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: This guide presents custom encryption code and protocol-specific constructions in a way that could be copied into general-purpose applications without clear warnings against reuse. That is dangerous because developers may deploy unauthenticated, nonstandard crypto outside its narrow protocol context, where modern authenticated encryption is required and bespoke constructions are especially error-prone.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 97% confidence
Finding: The document states that IGE 'provides integrity checking through error propagation,' which is misleading because error propagation is not authentication and does not prevent active tampering. Readers implementing this as written may omit a real MAC or authenticated-encryption check, enabling message modification, malleability, and forgery attacks in systems derived from the guide.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 94% confidence
Finding: The temporary-key generation section uses SHA-1 in a derivation flow without clearly labeling it as legacy, protocol-bound behavior. Even if required for MTProto interoperability, presenting it without a strong warning can lead implementers to reuse SHA-1-based derivation in new systems, weakening cryptographic design choices and propagating obsolete practices.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: The document claims to provide a complete MTProto 2.0 handshake, but its example uses RSA-OAEP for encrypting req_DH_params data, which is not MTProto's specified RSA processing. Implementers who follow this guidance will produce incompatible or noncompliant handshake code, and in security protocols, such deviations can cause failed interoperability or subtle security assumptions to break.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 91% confidence
Finding: The document states that message IDs include a direction bit, but the generator implementation only combines a timestamp with a counter and never encodes direction. This inconsistency can lead to non-compliant or colliding message IDs, replay/ordering validation failures, and interoperability bugs in MTProto implementations, especially since this skill is explicitly intended to guide backend protocol development.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 96% confidence
Finding: The documented TL string format says long strings use a 3-byte length form after the 0xfe marker, but the example emits four prefix bytes total: 0xfe plus three little-endian length bytes. In TL, this encoding is also subject to 4-byte alignment/padding rules; incorrect examples in a protocol implementation guide can cause interoperable parsers/encoders to be implemented incorrectly, leading to malformed message handling, desynchronization, parse failures, or unsafe downstream decoding assumptions in security-sensitive MTProto code.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Low

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The file gives contradictory descriptions of IGE error behavior, saying corruption garbles all remaining blocks while later claiming decryption resynchronizes after two blocks. In security documentation, such contradictions can cause incorrect reimplementation, faulty testing expectations, and unsafe error-handling logic around tampering or corruption.
Content: No source excerpt is available for this finding.

Missing User Warnings

Low

Category: Not specified by scanner
Confidence: 80% confidence
Finding: This markdown file describes and exemplifies a client-server handshake that sends nonces, factored parameters, and encrypted payloads over the network, but it does not include any warning or disclosure about network transmission behavior. Under the markdown-file criteria for missing user warnings, descriptions should warn when behavior may affect privacy or system integrity.
Content: No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.