Back to skill

Security audit

Ssl Certificate Monitor

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent SSL certificate checker, but its validation and compliance claims are materially stronger than what the code actually verifies.

Review before installing if you need real TLS security validation or compliance evidence. This tool is suitable only for basic certificate retrieval, metadata, and expiration checks unless the validation logic is fixed to verify hostname and trust chain.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/main.py:18
Finding
TLS certificate verification is disabled while the command reports successful validation<![CDATA[ ## Vulnerability Details **File Location**: `scripts/main.py:18-31` and `scripts/main.py:270-292` **Vulnerability Type**: Improper certificate and hostname validation **Risk Level**: High ### Vulnerable Code ```python def get_certificate(hostname: str, port: int = 443, timeout: int = 10) -> Optional[bytes]: """Get SSL certificate from host.""" try: context = ssl.create_default_context() context.check_hostname = False context.verify_mode = ssl.CERT_NONE with socket.create_connection((hostname, port), timeout=timeout) as sock: with context.wrap_socket(sock, server_hostname=hostname) as ssock: cert_der = ssock.getpeercert(binary_form=True) return cert_der except Exception as e: return None ``` The unauthenticated certificate retrieval is subsequently presented as validation: ```python def validate_command(args): """Handle validate command (basic chain validation).""" # Note: This is a simplified validation result = check_certificate(args.domain, args.port) if result['status'] not in ['valid', 'expiring_soon']: print(f"❌ Cannot validate: {result['error']}") return print(f"🔒 Basic validation for {result['domain']}:{result['port']}") print(f"✓ Certificate retrieved successfully") print(f"✓ Certificate is {'expired' if result['status'] == 'expired' else 'currently valid'}") print(f"✓ Issuer: {result['issuer']}") if result['days_remaining'] is not None: if result['days_remaining'] > 30: print(f"✓ Expiration: {result['days_remaining']} days remaining (good)") elif result['days_remaining'] > 0: print(f"⚠ Expiration: {result['days_remaining']} days remaining (renew soon)") else: print(f"✗ Expiration: Certificate expired {abs(result['days_remaining'])} days ago") if not CRYPTOGRAPHY_AVAILABLE: print("⚠ Advanced val ...[truncated 2761 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Preserve the secure defaults when performing validation: ```python context = ssl.create_default_context() context.verify_mode = ssl.CERT_REQUIRED context.check_hostname = True ``` 2. Separate authenticated validation from diagnostic certificate retrieval: - The `validate` command must use a verification-enabled TLS context. - If the tool needs to inspect expired, self-signed, or otherwise invalid certificates, provide a separately named inspection mode. - Clearly label inspection results as unverified and never assign them a trusted `valid` status. 3. Return distinct result fields for: - Certificate parsing success - Validity-period status - Hostname match - Chain trust - Revocation status, if supported 4. Catch `ssl.SSLCertVerificationError` separately and expose its verification code and message without converting the result into a generic connection failure. 5. Ensure the `validate` command reports success only when chain verification and hostname verification both succeed. 6. Update `README.md` and `SKILL.md` so the documented validation guarantees exactly match the implemented checks. If revocation checking is not implemented, state that limitation explicitly. 7. Add tests using: - A trusted certificate for the correct hostname - A self-signed certificate - A trusted certificate for the wrong hostname - An expired certificate - An incomplete or untrusted chain ]]>

T08 · Insecure Dependencies

Note
Location
SKILL.md:164
Finding
Third-party dependency installation is unpinned and lacks integrity verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:164-166` and `README.md:27-29` **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Low ### Vulnerable Code `SKILL.md` instructs users to install the dependency without a version or hash: ```bash pip3 install cryptography ``` The same instruction appears in `README.md`: ```bash pip3 install cryptography ``` ### Technical Analysis The installation instructions resolve `cryptography` and its applicable transitive dependencies from the configured Python package index at installation time. No exact version, lock file, package hash, or trusted repository constraint is supplied. The package name itself is not evidence of a malicious dependency, and the audited project does not contain a suspicious package source. The weakness is that installations are not reproducible and do not verify that the resolved artifact is the exact artifact reviewed by the project maintainer. The risk can materialize if a package index, configured mirror, dependency account, release artifact, or resolution environment is compromised. An unexpectedly incompatible future release could also change runtime behavior. ### Attack Path 1. A user follows the documented `pip3 install cryptography` instruction. 2. `pip` resolves the package from the user's configured index or mirror at that time. 3. A compromised index, mirror, maintainer account, or artifact supplies an altered release, or dependency resolution selects an unintended future version. 4. The package is installed without comparison against a project-approved version and cryptographic hash. 5. Installation-time or import-time package code executes with the privileges of the user running `pip` or the monitoring tool. This path requires an external supply-chain compromise or an unsafe package-index configuration; no such compromise is present in the audited repository itself. ### Impact Assessment If the dependency source or resolved ...[truncated 474 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin `cryptography` to a reviewed, compatible version rather than resolving an unrestricted latest version. 2. Maintain dependencies in a dedicated requirements or lock file, for example: ```text cryptography==<reviewed-version> \ --hash=sha256:<verified-wheel-hash> ``` 3. Generate hashes for every supported distribution artifact and install with hash enforcement: ```bash python3 -m pip install --require-hashes -r requirements.txt ``` 4. Review and update pinned versions through a controlled dependency-update process that includes vulnerability scanning and regression testing. 5. Recommend installation in an isolated virtual environment rather than into the system Python environment. 6. Where operationally appropriate, document the approved package index and use a trusted internal mirror or repository policy. 7. Avoid presenting `pip3 install cryptography` as the primary production installation method once a locked dependency file is available. ]]>
Vulnerability Patterns
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • 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
Findings (4)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
The skill materially overstates its security and compliance capabilities, especially by presenting 'validate' functionality as certificate validation while the underlying behavior reportedly disables SSL verification and performs only superficial checks. This can create false assurance, causing users to trust invalid, misissued, or hostname-mismatched certificates and to miss real security issues during monitoring or audits.

Lp3

Medium
Category
MCP Least Privilege
Confidence
70% confidence
Finding
Without declared permissions the skill's intent is opaque and cannot be validated.

Description-Behavior Mismatch

Medium
Confidence
96% confidence
Finding
The skill description claims monitoring for SSL/TLS security issues and compliance, but the implementation primarily fetches certificates and reports expiration metadata. This mismatch can mislead operators into believing broader certificate security and compliance checks are being performed when they are not, creating a false sense of assurance and leaving hostname validation, trust validation, weak algorithm detection, and policy/compliance failures unnoticed.

Intent-Code Divergence

Medium
Confidence
99% confidence
Finding
The validate command is presented as certificate validation, but get_certificate() explicitly disables hostname checking and certificate verification via check_hostname=False and verify_mode=ssl.CERT_NONE. As a result, the tool may report successful 'validation' for untrusted, self-signed, mismatched, or attacker-supplied certificates, which is dangerous if users rely on this output for security decisions.

Static analysis

No suspicious patterns detected.