PlovCoin

We express our gratitude to the PlovCoin team for the collaborative engagement that enabled the execution of this Pentest.

The system users should acknowledge all the risks summed up in the risks section of the report

{FindingsVulnSeverityStatusTable}

VPS Infrastructure Scope of Review

Overview

The VPS infrastructure was assessed across six security domains: SSH and access control, firewall and network exposure, externally accessible services, system hardening, secrets and permissions management, and operational persistence.

Testing was performed using a dedicated audit account with key-based authentication and a restricted set of read-only administrative permissions.

The assessment identified ten findings covering credential management, service configuration, filesystem permissions, operating-system hardening, patch management, resource utilization, and operational security.

SSH and Access Control

SSH configuration and administrative access controls were reviewed through both client-side testing and server-side configuration analysis.

The assessment included password and key-based authentication policies, privileged login restrictions, authentication limits, configuration consistency, local user accounts, administrative group memberships, privilege-management rules, authorized keys, authentication logs, and the presence of private SSH keys.

The isolation and privilege boundaries of the dedicated audit account were also verified.

Firewall and Network Exposure

Host-based firewall configuration, default policies, and network-access rules were reviewed.

Listening services were enumerated and compared against configured firewall rules. Services bound to externally accessible interfaces and local-only interfaces were identified, and IPv4 and IPv6 exposure was assessed.

Active outbound connections and TCP connection states were additionally reviewed for unexpected communication patterns or abnormal connection behavior.

InternetExposed Services

Network-accessible application and management services were assessed for authentication enforcement, unauthorized access, information disclosure, unsafe HTTP behavior, input-handling weaknesses, and unnecessary network exposure.

Testing included attempts to access protected functionality through alternative authentication mechanisms and review of potentially sensitive application paths.

Specific service names, ports, endpoints, and infrastructure details have been omitted from this public version of the report.

System Hardening

The operating-system and host-security configuration was reviewed, including:

• Operating-system and kernel patch status

• Pending security updates and reboot requirements

• Running processes and privilege levels

• Resource consumption and process runtime

• SUID and SGID executables

• Linux capabilities

• Kernel security parameters

• Installed system packages

• Container runtime configuration

The assessment also reviewed whether unnecessary software or privileged functionality increased the attack surface of the host.

Secrets Permissions and Configuration

System and application configuration locations were reviewed for insecure storage or disclosure of credentials, API keys, tokens, passwords, and other sensitive information.

The assessment included service configurations, backup files, environment configuration, filesystem permissions and ownership, process environments, command-line arguments, shell configuration and history, scheduled tasks, accessible system logs, and application source repositories.

World-writable resources and ownership anomalies within system-wide locations were additionally reviewed.

Operational Persistence and Privilege Escalation

Custom services, persistent terminal sessions, scheduled tasks, watchdog mechanisms, and other persistence mechanisms were reviewed.

A privilege-escalation assessment was performed across common Linux attack vectors, including insecure filesystem permissions, privileged executables, environment and path manipulation, scheduled-task abuse, Linux capabilities, container-related privileges, shared session access, and applicable operating-system vulnerabilities.

No privilege-escalation path from the dedicated audit account was identified during testing.

Custody Architecture Scope of Review

Overview

The multisignature custody and governance architecture was reviewed across three domains: architecture and threshold design, authority and custody management, and independent verification of the deployed on-chain state.

The assessment covered the documented governance specification and independently compared the deployed blockchain configuration against the intended architecture.

The custody infrastructure had been rebuilt using hardware-based signing keys while preserving the intended governance thresholds, timelocks, permissions, and membership structure.

Architecture and Governance Design

The multisignature structure was reviewed for functional separation, threshold adequacy, signer distribution, governance permissions, and single-point-of-failure risks.

The primary treasury configuration uses a more conservative signing threshold and longer execution delay than operational governance components, while operational multisignature groups use configurations designed to balance governance control with operational requirements.

Signer distribution was reviewed to verify that quorum could be reached without dependence on a single individual.

Member permissions and optional governance modules were also reviewed to identify unnecessary privilege asymmetry or additional attack surface.

Authority and Custody Management

Token-level authorities were independently reviewed on-chain to verify their configured state.

The custody model, planned authority transfers, hardware-wallet signing procedures, and associated operational limitations were assessed.

Signer-control procedures were also reviewed using independently verifiable on-chain activity to confirm that designated signing keys could participate in governance operations and that configured execution delays were enforced by the underlying governance mechanism.

Specific wallet addresses, transaction signatures, token quantities, and other sensitive operational details have been omitted from this public version of the report.

OnChain State Verification

The documented governance configuration was independently compared against the deployed blockchain state.

Verification included:

• Multisignature vault configuration

• Signing thresholds

• Timelock durations

• Membership configuration

• Governance permissions

• Token authority configuration

• Configuration authority settings

• Governance-program usage

• Signer ceremony transactions

• Status of deprecated governance deployments

The verified on-chain parameters were consistent with the intended governance architecture.

CrossDocument Consistency

Governance and custody information was cross-referenced across the supporting project documentation.

Allocation information, signer structures, vault configuration, and governance design were generally consistent across the reviewed materials.

A historical documentation inconsistency affecting a treasury threshold reference was identified. The discrepancy related to an earlier design and did not reflect the deployed governance configuration.

Conclusion

The independently verified on-chain configuration was consistent with the documented governance architecture across the reviewed security parameters.

The architecture demonstrated appropriate separation of governance responsibilities, multisignature approval requirements, hardware-based signer custody, and programmatically enforced execution delays.

Frontend Source Code Scope of Review

Overview

The frontend source code was reviewed for application-security vulnerabilities, dependency risks, and configuration weaknesses.

The assessed application was confirmed to be primarily static and presentational, without wallet connectivity, blockchain transactions, user authentication, form submissions, application API endpoints, or database interaction.

Two findings were identified. The application's attack surface was considered limited due to its static architecture.

Controls Performed

Application Architecture and Attack Surface

The frontend source code, application components, configuration files, middleware, and supporting modules were manually reviewed.

The application architecture was assessed for server-side functionality, dynamic routing, API functionality, user-controlled data flows, and other components that could introduce exploitable application behavior.

Input Handling and Injection Vectors

Application components were reviewed for user-controlled input and common client-side injection vectors.

Potentially dangerous browser and framework functionality associated with dynamic code execution or unsafe HTML rendering was specifically reviewed.

No exploitable cross-site scripting or equivalent injection vector was identified in the reviewed implementation.

Authentication and Session Management

The application did not implement user authentication or authenticated session management.

Client-side state and cookie usage were reviewed to determine whether authentication material or other sensitive information was stored or transmitted insecurely.

A non-sensitive preference cookie was identified and its security attributes were assessed separately.

Network Communication

The source code was reviewed for runtime network communication and external application integrations.

No application-controlled runtime API communication or backend application interface was identified within the reviewed frontend implementation.

Third-party integrations were reviewed for their relevance to the application's security boundary.

Dependency Analysis

Third-party application dependencies were reviewed for publicly known security vulnerabilities and their applicability to the application's actual implementation.

The assessment considered both dependency versions and whether vulnerable functionality was reachable within the application.

Security Headers and Transport Configuration

Application security-header configuration was reviewed, including controls related to:

• Content Security Policy

• Clickjacking protection

• MIME-type enforcement

• HTTP Strict Transport Security

• Referrer handling

• Browser permissions

The effectiveness and restrictiveness of the configured policies were evaluated against the application's architecture.

Middleware and Routing

Application middleware and routing logic were reviewed for unsafe redirects, user-controlled destinations, routing manipulation, and related authorization or input-validation weaknesses.

Redirect and rewrite behavior was assessed to verify that destinations were appropriately constrained and could not be manipulated into redirecting users to attacker-controlled locations.

Specific domains, repository information, source-code locations, route names, cookie names, framework configuration details, and other implementation-specific information have been omitted from this public version of the report.

PlovCoin ($PLOV) is a cultural memecoin on Solana built around plov a culinary tradition shared across Central Asia, South Asia, and the Middle East. The token uses the standard SPL Token Program with a fixed supply of 13,013,003,000 PLOV, mint and freeze authorities permanently revoked at deployment. The project operates a fair-launch model with no presale, no private sale, and a 45% community airdrop allocation distributed across four waves.

The assessed infrastructure consists of three components: a Linux VPS (Ubuntu 24.04) hosting the project's operational agent system, trading services, and monitoring stack; a Squads V4 multisig custody layer on Solana mainnet governing treasury, liquidity, marketing, metadata, and burn operations across five separately configured Squads; and a static Next.js front-end serving the public website and claim portal placeholder at plovcoin.com.

The scope of the project includes the following: