# Voke Cyber — Complete Site Content > Expert penetration testing services based in the Charlotte, NC area. No fillers, just findings. Speak directly with the tester performing your assessment. --- ## Home URL: https://vokecyber.com/ ### Penetration Testing. No Fillers. Just Findings. A streamlined, expert-driven approach to security testing. Speak directly with the tester performing your assessment, receive real-time updates, and get clear, actionable results without the friction of traditional consulting. ### Why Work With Us **Retesting Included** Every pentest — even the smallest — includes a full round of retesting at no extra cost, with a minimum 30-day window for your team to apply fixes before validation. **Streamlined Process** From kickoff to final report, our workflow is optimized for speed and clarity. Once contracts are signed, we can generally start testing within 24 hours for most assessments. **Transparent Pricing** Clear, predictable pricing with no unnecessary add-ons, upsells, or sales calls. You get exactly what you need — nothing more, nothing less. **Direct Communication** No account managers. No layers. You talk directly with the owner and tester performing your assessment for faster answers and better outcomes. **Experienced Security Professionals** Each tester brings 5+ years of hands-on experience in offensive security, specializing in application, API, mobile, cloud, and network testing. **Actionable Reporting** Findings are written in plain English with business impact, risk scoring, and step-by-step remediation guidance your developers can use immediately. ### Our Core Services - **Web Application Penetration Testing**: OWASP WSTG-aligned testing of your web applications for vulnerabilities in authentication, authorization, and business logic. - **API Security Testing**: Full-scope testing of REST, GraphQL, and other API architectures against the OWASP API Top 10. - **Mobile App Testing**: Security evaluation of iOS and Android applications including reverse engineering, local storage, and backend communication. - **External Network Testing**: Black-box assessment of your internet-facing infrastructure from an attacker's perspective. ### Trusted Expertise - OSCP Certified — Offensive Security Certified Professional - OSWA Certified — Offensive Security Web Assessor - 1,000+ Pentests — Completed Assessments - US-Based — All Work Performed Domestically - CISSP — Certified Information Systems Security Professional ### Industries We Serve - **Finance & FinTech**: Protect customer data, prevent fraud, and meet regulatory expectations. Testing focuses on authentication, transaction integrity, and API security. - **Healthcare**: Safeguard patient data and ensure secure integrations with EHR systems. Testing targets PHI exposure, access control, and insecure APIs. - **SaaS Platforms**: Multi-tenant logic testing, API abuse prevention, and secure user onboarding flows to protect your platform and customers. - **E-Commerce**: Secure payment flows, prevent account takeover, and protect customer data from injection and logic-based attacks. - **Manufacturing**: Secure internal networks, OT/IT integrations, and cloud-connected devices to prevent operational disruption. - **Education**: Protect student data, secure online portals, and prevent unauthorized access to internal systems. ### Client Testimonial "Louis Sanchez has worked with us over the last three years conducting Penetration Tests on our SaaS Web Application, Network and Vulnerability Scans, and generally helping us increase our security posture as an organization. He runs our quarterly vulnerability assessments and produces the annual third-party reports we provide to clients as a part of our security review process. As a growing organization, he has been essential in scaling our security practices and procedures and assisting us with rolling out upgrades across the organization. We would not be where we are without his knowledge and assistance. He is also enjoyable to work with, always on time with deliverables, and willing to help with whatever questions or issues arise." — Katie Wolf, Head of Development, MeasuringU --- ## About Us URL: https://vokecyber.com/about ### About Voke Cyber Voke Cyber is a specialized penetration testing firm backed by a team of seasoned offensive security professionals. With 1,000+ penetration tests completed, we bring proven expertise to every engagement. We believe security assessments should be straightforward — no unnecessary complexity, no filler reports, just real findings that help you improve your security posture. ### Why Voke Cyber - **US-Based**: All work performed domestically - **5+ Years Minimum**: Every tester is highly experienced - **Direct Communication**: Talk directly with the owner and tester - **Retesting Included**: 30-day retest window at no cost ### Leadership **Louis Sanchez** — Founder & Principal Security Consultant Louis founded Voke Cyber to create the kind of security consultancy he wished existed — one focused on delivering value through expertise rather than volume. He leads every engagement with a hands-on approach, ensuring clients receive actionable insights from someone who truly understands their challenges. With 18 years of Information Security experience and 7+ years in Offensive Security, Louis has assessed networks, cloud environments, APIs, mobile applications, and complex enterprise systems for organizations of all sizes. Louis maintains certifications including OSCP, OSWA, CISSP, and CCSK — along with recognition as one of the first professionals certified in Metasploit Pro. ### Location Based in the Charlotte, NC area — delivering clear, actionable guidance to help organizations strengthen their security posture with confidence. Serving the Greater Charlotte Region and beyond. --- ## Services Overview URL: https://vokecyber.com/services Tailored penetration testing designed to protect your digital assets, strengthen long-term security, and ensure compliance with industry standards. We identify vulnerabilities before attackers do. ### Web Application Security Comprehensive testing aligned with OWASP WSTG, evaluating authentication, authorization, session handling, business logic, and input validation. ### Developer API Security Focused API penetration testing aligned with OWASP API Top 10, evaluating authorization weaknesses, rate-limiting gaps, and sensitive data exposure. ### Mobile Application Testing Mobile security assessments aligned with OWASP MSTG, including static and dynamic analysis, insecure data storage detection, and API communication testing. ### Network Assessments External and internal network penetration testing aligned with PTES, identifying exploitable weaknesses and real-world attack paths. ### Cloud Security Assessments Cloud environment evaluations based on CIS Benchmarks, reviewing identity configurations, permissions, and exposed services across AWS, Azure, and GCP. ### Phishing Simulation & Training Targeted phishing campaigns using industry-standard tooling, paired with behavioral analytics and follow-up training to reduce human-factor vulnerabilities. ### LLM/AI Penetration Testing Security assessments for LLMs, AI agents, and RAG pipelines aligned with the OWASP LLM Top 10 2025, testing for prompt injection, sensitive information disclosure, supply chain risks, and more. ### Red Teaming Full-scope adversary simulation aligned with MITRE ATT&CK framework, replicating real-world threat actor TTPs to test detection and response capabilities. ### Thick Client Applications In-depth security testing of desktop applications, analyzing client-server communication, local storage, memory handling, and reverse-engineering resilience. ### IoT & Embedded Systems Hardware and firmware security assessments covering device interfaces, communication protocols, firmware extraction, and embedded OS vulnerabilities. ### PCI Scanning PCI DSS-compliant vulnerability scanning using Approved Scanning Vendor (ASV) methodology to validate your cardholder data environment and maintain compliance. --- ## Web Application Penetration Testing URL: https://vokecyber.com/services/web-application A comprehensive security evaluation of your web application, combining automated scanning with deep manual testing to uncover vulnerabilities in authentication, authorization, data validation, business logic, and server configuration. **Methodology**: OWASP WSTG v5, Manual Exploitation, Business Logic, Free Retesting ### What We Test - **Information Gathering**: Application mapping, endpoint discovery, and tech stack identification to understand your attack surface. - **Authentication Testing**: Weak password policies, default credentials, session fixation, MFA bypass, and account enumeration. - **Authorization Testing**: Broken access controls, IDOR, privilege escalation, and horizontal/vertical permission bypass. - **Data Validation**: SQLi, XSS, command injection, template injection, and other injection vulnerabilities. - **Client-Side Testing**: Clickjacking, DOM-based XSS, local storage abuse, and insecure client-side controls. - **Cryptography**: TLS validation, weak ciphers, improper key management, and secure transmission verification. ### Our Methodology 1. **Reconnaissance**: Application mapping, technology fingerprinting, and attack surface enumeration. 2. **Testing**: Manual and automated testing following OWASP WSTG across all security categories. 3. **Exploitation**: Safe exploitation to validate findings and demonstrate real-world impact. 4. **Reporting**: Detailed findings with risk ratings, proof-of-concept, and remediation guidance. ### What You'll Receive - **Executive Summary**: High-level overview of findings, risk posture, and key recommendations for leadership and stakeholders. - **Technical Findings**: Detailed vulnerability descriptions with CVSS scoring, proof-of-concept, and step-by-step reproduction steps. - **Remediation Guidance**: Actionable fix recommendations with code examples where applicable, prioritized by risk level. - **Free Retesting**: Complimentary retest of all findings within 30 days to validate your remediation efforts. --- ## API Security Testing URL: https://vokecyber.com/services/api A full-scope penetration test of REST, GraphQL, or other API architectures, evaluating authentication, authorization, data exposure, and endpoint behavior. **Methodology**: OWASP API Top 10, REST & GraphQL, Manual Testing, Free Retesting ### OWASP API Security Top 10 Coverage - **API1: Broken Object Level Authorization** — Testing for unauthorized access to objects by manipulating IDs in API requests. - **API2: Broken Authentication** — Weak authentication mechanisms, token flaws, credential handling issues. - **API3: Broken Object Property Level Authorization** — Excessive data exposure through property-level access control flaws and mass assignment. - **API4: Unrestricted Resource Consumption** — Missing or inadequate rate limiting enabling brute force and DoS. - **API5: Broken Function Level Authorization** — Unauthorized access to admin functions and privilege escalation. - **API6: Unrestricted Access to Sensitive Flows** — Business logic flaws, workflow bypasses, abuse of sensitive business flows. - **API7: Server Side Request Forgery** — SSRF vulnerabilities allowing requests to internal resources through the API. - **API8: Security Misconfiguration** — Insecure defaults, verbose errors, CORS misconfigurations, missing security headers. - **API9: Improper Inventory Management** — Undocumented endpoints, deprecated API versions, shadow APIs. - **API10: Unsafe Consumption of APIs** — Vulnerabilities from trusting third-party APIs without proper validation. ### Methodology 1. **Discovery** — API endpoint enumeration, schema analysis, and authentication flow mapping. 2. **Testing** — Authenticated and unauthenticated testing across all OWASP API Top 10 categories. 3. **Exploitation** — Real-world exploitation scenarios demonstrating business impact. 4. **Reporting** — Clear mapping of vulnerabilities to business risk with remediation guidance. --- ## Mobile Application Testing URL: https://vokecyber.com/services/mobile A full security evaluation of iOS and Android applications, including local storage, authentication, encryption, and backend communication. **Methodology**: iOS & Android, Reverse Engineering, OWASP Mobile Top 10, Free Retesting ### OWASP Mobile Top 10 (2024) Coverage - **M1: Improper Credential Usage** — Hardcoded credentials, improper storage, insecure transmission. - **M2: Inadequate Supply Chain Security** — Third-party libraries, SDKs, and dependency vulnerabilities. - **M3: Insecure Authentication/Authorization** — Authentication bypasses, session management flaws. - **M4: Insufficient Input/Output Validation** — Injection attacks, improper sanitization. - **M5: Insecure Communication** — TLS implementation, certificate pinning, MITM attacks. - **M6: Inadequate Privacy Controls** — PII handling, data minimization, GDPR/CCPA compliance. - **M7: Insufficient Binary Protections** — Anti-tampering, obfuscation, root/jailbreak detection. - **M8: Security Misconfiguration** — App permissions, debug settings, backup configurations. - **M9: Insecure Data Storage** — Local databases, shared preferences, keychain/keystore security. - **M10: Insufficient Cryptography** — Encryption algorithms, key management, cryptographic implementation. ### Methodology 1. **Static Analysis** — Binary decompilation, code review, and configuration analysis. 2. **Dynamic Analysis** — Runtime testing, traffic interception, and behavior monitoring. 3. **API Testing** — Backend integration security and authentication flow analysis. 4. **Reporting** — Detailed findings with platform-specific remediation guidance. --- ## Cloud Security Assessment URL: https://vokecyber.com/services/cloud A white-box configuration review of AWS, Azure, or GCP environments, identifying misconfigurations that lead to breaches and strengthening your cloud security posture. **Methodology**: AWS / Azure / GCP, CIS Benchmarks, IAM Analysis, Compliance Mapping ### Supported Platforms - **Amazon Web Services** — IAM, S3, EC2, Lambda, VPC, CloudTrail - **Microsoft Azure** — Azure AD, Storage, VMs, Functions, NSGs, Activity Logs - **Google Cloud Platform** — IAM, Cloud Storage, Compute, VPC, Audit Logs ### What We Review - **IAM Review** — Roles, permissions, MFA enforcement, trust relationships, least privilege analysis. - **Storage Security** — Public buckets, encryption at rest, versioning, and access policies. - **Network Configuration** — Security groups, VPC segmentation, network ACLs, peering configurations. - **Compute Security** — VM/container hardening, instance metadata, serverless configurations. - **Logging & Monitoring** — CloudTrail, Activity Logs, Flow Logs, and alerting configurations. - **Secrets & Key Management** — KMS, vaults, certificates, and secrets rotation policies. --- ## Network Penetration Testing URL: https://vokecyber.com/services/network Comprehensive network security assessments to test your infrastructure from multiple perspectives. External pentest, internal pentest, and vulnerability assessment services. ### Sub-Services - **External Penetration Testing** — Evaluate your internet-facing attack surface from an outsider's perspective. - **Internal Penetration Testing** — Simulate an insider threat or compromised workstation scenario. - **Vulnerability Assessment** — Comprehensive scanning with prioritized remediation guidance. --- ## External Penetration Testing URL: https://vokecyber.com/services/external-pentest A comprehensive assessment of your internet-facing infrastructure, identifying vulnerabilities in perimeter defenses, exposed services, and public-facing applications before attackers do. **Methodology**: Perimeter Testing, OSINT Analysis, Manual Testing, Free Retesting ### What We Test - **Perimeter Service Enumeration** — All externally exposed services, ports, and entry points. - **Authentication Testing** — Login portals, VPN endpoints, and remote access bypass. - **Web Application Assessment** — OWASP Top 10 on externally facing web applications. - **Email Security Analysis** — Email spoofing, open relays, SMTP vulnerabilities. - **DNS Security Review** — Zone transfers, subdomain takeover, dangling DNS records. - **SSL/TLS Configuration** — Certificate validity, cipher strength, protocol versions. - **Remote Access Exploitation** — SSH, RDP, VPN, and other remote access exploitation. - **Public Information Gathering** — OSINT for exposed credentials and leaked data. ### Methodology 1. **Reconnaissance** — OSINT gathering, asset discovery, attack surface mapping. 2. **Enumeration** — Port scanning, service identification, vulnerability assessment. 3. **Exploitation** — Manual exploitation demonstrating real-world attack scenarios. 4. **Reporting** — Detailed findings with risk ratings, proof-of-concept, and remediation steps. --- ## Internal Penetration Testing URL: https://vokecyber.com/services/internal-pentest A comprehensive assessment of your internal network environment, simulating an attacker who has gained initial access to identify privilege escalation paths, lateral movement opportunities, and critical vulnerabilities. **Methodology**: Active Directory, Credential Attacks, Lateral Movement, Free Retesting ### What We Test - **Active Directory Assessment** — Users, groups, policies, trust relationships, misconfigurations. - **Credential Harvesting** — LLMNR/NBT-NS poisoning, responder attacks, network traffic analysis. - **Privilege Escalation** — Local and domain privilege escalation paths. - **Lateral Movement** — Pass-the-hash, token impersonation, RDP pivoting. - **Network Segmentation Testing** — Verify isolation between network zones. - **Service Account Analysis** — Overprivileged or misconfigured service accounts. - **Kerberoasting & AS-REP Roasting** — Weak service account passwords via Kerberos ticket cracking. - **Internal Web App Testing** — Internal portals and management interfaces. ### Methodology 1. **Reconnaissance** — Network enumeration, service discovery, Active Directory mapping. 2. **Exploitation** — Credential attacks, vulnerability exploitation, privilege escalation. 3. **Post-Exploitation** — Lateral movement, domain escalation, persistence mechanism testing. 4. **Reporting** — Attack paths, business impact analysis, prioritized remediation steps. --- ## Red Team Assessment URL: https://vokecyber.com/services/red-team A covert, multi-week simulation of a real-world advanced threat actor targeting your organization. The closest you can get to a real breach without the damage. Aligned with MITRE ATT&CK framework. **Methodology**: Stealth Operations, Real Tradecraft, Objective-Based, Free Retesting ### Attack Techniques - **OSINT & Reconnaissance** — Employee enumeration, technology profiling, attack surface mapping. - **Phishing & Social Engineering** — Targeted campaigns designed to bypass security awareness. - **Exploitation** — Custom payloads and exploit chains that evade EDR and security controls. - **Lateral Movement** — Living-off-the-land techniques across your network. - **Privilege Escalation** — Escalate from standard user to domain administrator access. - **Data Exfiltration** — Demonstrate extraction of sensitive data through covert channels. ### Operation Phases 1. **OSINT Reconnaissance** — Gather intelligence on your organization through open sources. 2. **Initial Access** — Phishing, social engineering, or technical exploitation to gain foothold. 3. **Stealthy Persistence** — Establish persistence that evades detection. 4. **Objective Completion** — Achieve pre-defined objectives (data exfiltration, domain compromise, etc.). --- ## Phishing Simulation & Training URL: https://vokecyber.com/services/phishing A realistic phishing campaign designed to measure employee awareness and susceptibility. Identify high-risk users and improve your security culture with measurable training outcomes. **Features**: Realistic Templates, Behavioral Analytics, User Education, Executive Reporting ### How It Works 1. **Template Selection** — Customized phishing templates tailored to your organization. 2. **Controlled Delivery** — Safe delivery to designated staff over your preferred timeframe. 3. **Tracking** — Monitor opens, clicks, and credential submissions in real-time. 4. **Education** — Immediate educational feedback for users who interact. 5. **Reporting** — Executive-level reporting with actionable insights. --- ## LLM/AI Penetration Testing URL: https://vokecyber.com/services/ml-ai Offensive security assessments for LLMs, AI agents, RAG pipelines, and AI-powered applications. Aligned with the OWASP LLM Top 10 2025. **Methodology**: OWASP LLM Top 10, Prompt Injection, AI Red Teaming, Free Retesting ### OWASP LLM Top 10 (2025) Coverage - **LLM01: Prompt Injection** — User prompts that alter the LLM's intended behavior, bypassing safety guardrails or triggering unauthorized actions. - **LLM02: Sensitive Information Disclosure** — Sensitive information leaking through LLM outputs, exposing PII, credentials, or training data. - **LLM03: Supply Chain** — Vulnerabilities in third-party models, training data, plugins, and dependencies. - **LLM04: Data and Model Poisoning** — Corrupted pre-training, fine-tuning, or embedding data that manipulates model behavior. - **LLM05: Improper Output Handling** — Insufficient validation of LLM outputs leading to XSS, SSRF, or code execution in downstream systems. - **LLM06: Excessive Agency** — LLM-based systems granted too much autonomy, executing unintended actions or accessing sensitive systems. - **LLM07: System Prompt Leakage** — Extraction of system prompts revealing internal logic, security controls, or sensitive configuration. - **LLM08: Vector and Embedding Weaknesses** — Security risks in vector databases and embedding systems, including poisoned embeddings and retrieval manipulation. - **LLM09: Misinformation** — LLM-generated false or misleading content that applications rely on for decision-making. - **LLM10: Unbounded Consumption** — Resource exhaustion through unconstrained LLM usage, denial of wallet attacks, and excessive token consumption. ### Additional Attack Techniques - **Direct & Indirect Prompt Injection** — Bypass guardrails via user input or poisoned external data sources. - **Jailbreaking & Guardrail Bypass** — Circumventing content policies and alignment through context manipulation. - **System Prompt Extraction** — Techniques to extract system prompts revealing internal logic. - **RAG Pipeline Exploitation** — Poisoning knowledge bases, manipulating retrieval, and exfiltrating data. - **Agent & Tool Abuse** — Exploiting agentic AI workflows for unauthorized tool calls and privilege escalation. --- ## EU AI Act Cybersecurity Assessment URL: https://vokecyber.com/services/eu-ai-act Technical security testing and compliance support for the EU AI Act (Regulation EU 2024/1689). The August 2, 2026 deadline applies to all Annex III high-risk AI systems — including US companies whose AI affects EU residents. **What We Assess:** - **Article 15 Adversarial Robustness Testing**: Adversarial examples, evasion attacks, prompt injection, indirect prompt injection, jailbreaking, backdoor detection, goal hijacking in agentic AI. - **Data Pipeline Security (Article 10)**: Training data poisoning vulnerability assessment, ML supply chain audit, MLOps pipeline security, feature store and model registry access controls. - **Bias & Fairness Testing (Articles 10 + 15)**: Disaggregated performance benchmarking by demographic, membership inference, model inversion, disparate impact analysis, FRIA technical evidence. - **AI Infrastructure Penetration Testing (Article 9)**: AI inference API security, cloud ML environment assessment (SageMaker, Vertex AI, Azure ML), model serving infrastructure, model extraction testing. - **GPAI & LLM Security Assessment (Article 55)**: Prompt injection, jailbreak resistance, multi-modal attacks, RAG pipeline exploitation, agentic AI tool-use security. Article 55 explicitly mandates red-teaming for systemic risk GPAI providers. - **Conformity Assessment Support (Articles 43–48 + Annex IV)**: Gap analysis, Annex IV technical documentation evidence package, post-market monitoring plan design, incident reporting procedure development. **Key Compliance Deadlines:** - February 2, 2025: Prohibited AI practices enforced - August 2, 2025: GPAI and governance requirements apply - August 2, 2026: Full application for Annex III high-risk AI systems - August 2, 2027: Extended deadline for legacy high-risk AI already on market **EU AI Act Risk Tiers:** - Unacceptable Risk: Banned outright (social scoring, real-time facial recognition in public spaces, subliminal manipulation) - High Risk: Full compliance required — Annex III sectors including employment AI, credit scoring, law enforcement, biometrics, critical infrastructure, education - Limited Risk: Transparency obligations only (chatbots must identify as AI, deepfakes must be labeled) - Minimal Risk: Voluntary codes of conduct **Penalties:** Up to €35M or 7% of global annual turnover for prohibited practice violations; up to €15M or 3% for high-risk system violations; up to €7.5M or 1% for incorrect information supplied to authorities. --- ## IoT & Embedded Systems Testing URL: https://vokecyber.com/services/iot A practical security assessment of IoT and embedded devices, focusing on real-world attack paths that adversaries actually use. Evaluates device interfaces, network communications, cloud integrations, and firmware security. **Methodology**: Device Interfaces, Network Security, Cloud API Testing, Firmware Review ### Assessment Scope - **Device Interface & Surface Mapping** — Enumerate ports (USB, Ethernet, serial), open network services, wireless interfaces (BLE, Wi-Fi). - **Network & Communication Security** — Intercept traffic, validate TLS, look for plaintext credentials, check replayability. - **Cloud API / Backend Security** — Test authentication/authorization, API key handling, insecure endpoints. - **Mobile App / Web App Integration** — Inspect API calls between app and device, validate authentication flows. - **Update Mechanism Review** — Check for signed updates, transport security, downgrade vulnerabilities. - **Basic Firmware Review** — String analysis, hardcoded credential search, static analysis, configuration review. - **Device Hardening Review** — Exposed debug ports, insecure reset mechanisms, default configurations. --- ## Thick Client Application Testing URL: https://vokecyber.com/services/thick-client A full evaluation of desktop/thick-client applications, including binary analysis, runtime manipulation, and communication security. Thick clients run on machines attackers fully control. **Methodology**: Binary Analysis, Runtime Testing, Memory Inspection, Free Retesting ### What We Test - **Static Binary Analysis** — Decompilation, code review, hardcoded secrets, insecure configurations. - **Dynamic Runtime Manipulation** — Debugging, hooking, runtime modification of application behavior. - **Memory Inspection** — Extract sensitive data from process memory including credentials and tokens. - **DLL Hijacking** — Identify and exploit insecure DLL loading paths for privilege escalation. - **Local Storage Review** — Configuration files, databases, registry keys, credential storage. - **TLS & Certificate Validation** — Secure communication, certificate pinning, traffic interception resistance. --- ## PCI Compliance Scanning URL: https://vokecyber.com/services/pci A PCI-approved external vulnerability scan aligned with PCI DSS Requirement 11.3.2. Maintain compliance with auditor-ready documentation and clear remediation guidance. **Features**: PCI DSS 11.3.2, ASV-Approved, Auditor-Ready, Weekly Scans ### What's Included - **ASV-Approved Scanning** — Vulnerability scanning by a PCI-approved Approved Scanning Vendor. - **External Perimeter Evaluation** — Complete assessment of internet-facing cardholder data environment. - **PCI-Aligned Reporting** — Auditor-ready documentation meeting PCI DSS requirements. - **Flexible Scanning Cycles** — Monthly or quarterly scanning for continuous compliance. - **Weekly Scans** — Ongoing scans throughout the quarter to catch issues before attestation deadlines. --- ## Vulnerability Assessment URL: https://vokecyber.com/services/vulnerability-assessment A comprehensive scan-based assessment that identifies security vulnerabilities across your infrastructure without attempting exploitation. Focuses on breadth of coverage to catalog all potential weaknesses. **Methodology**: Authenticated Scans, Compliance Mapping, Risk Prioritization, Remediation Guidance ### Assessment Capabilities - **Authenticated Scanning** — Credentialed scans for deeper vulnerability detection. - **Unauthenticated Scanning** — External perspective simulating what attackers see. - **Configuration Auditing** — Systematic review of system configurations against security baselines. - **Patch Validation** — Missing security patches across OS, applications, and firmware. - **Compliance Mapping** — Map findings to PCI DSS, HIPAA, SOC 2, NIST, and CIS benchmarks. - **Risk Prioritization** — Categorize by exploitability, business impact, and asset criticality. - **False Positive Validation** — Manual verification to eliminate scanner noise. - **Remediation Guidance** — Actionable fix recommendations with step-by-step instructions. ### Methodology 1. **Scoping** — Define boundaries, asset inventory, credential requirements. 2. **Scanning** — Execute scans using industry-leading vulnerability scanners. 3. **Analysis** — Manual review to validate findings and assess true business risk. 4. **Reporting** — Prioritized findings with compliance mapping and remediation guidance. --- ## Healthcare Penetration Testing URL: https://vokecyber.com/services/healthcare Protect patient data, PHI, and critical healthcare systems with HIPAA-aligned penetration testing. We help hospitals, health tech companies, and medical device manufacturers find and fix vulnerabilities before attackers exploit them. ### Security Challenges in Healthcare - **PHI & HIPAA Compliance** — Protected health information requires strict access controls and encryption. A single breach can trigger HIPAA penalties exceeding $1M and erode patient trust. - **EHR System Vulnerabilities** — Electronic health record systems are high-value targets. Misconfigurations, weak authentication, and unpatched software can expose millions of patient records. - **Medical Device Security** — Connected medical devices often run outdated firmware with limited security controls. Compromised devices can affect patient safety and create lateral movement paths. - **Patient Portal Security** — Patient-facing portals handle sensitive data including medical records, billing information, and personal identifiers. Authentication and authorization flaws are common attack vectors. - **Healthcare API Exposure** — HL7 FHIR and other healthcare APIs enable interoperability but also expand the attack surface. Insecure API endpoints can leak PHI or allow unauthorized data modification. - **Third-Party Integration Risks** — Healthcare organizations rely on dozens of third-party vendors and integrations. Each connection point is a potential entry for attackers. ### How We Help Healthcare Organizations - **Web Application Testing** — Comprehensive testing of patient portals, EHR web interfaces, telehealth platforms, and internal healthcare applications. - **API Security** — Security testing for HL7 FHIR, REST, and SOAP-based healthcare APIs. - **Network Penetration Testing** — Internal and external network assessments targeting hospital networks, clinical environments, and administrative systems. - **Cloud Security** — Security assessments for AWS, Azure, and GCP healthcare workloads. --- ## FinTech Penetration Testing URL: https://vokecyber.com/services/fintech Secure your financial applications, protect transaction integrity, and meet regulatory requirements like PCI DSS and SOC 2. We help fintech companies, banks, and payment processors find vulnerabilities before attackers do. ### Security Challenges in Financial Services - **Payment Processing Security** — Payment gateways, card-not-present flows, and tokenization systems are high-value targets. A single flaw can expose thousands of transactions and trigger costly PCI violations. - **Transaction Integrity** — Race conditions, rounding errors, and business logic flaws in transaction flows can be exploited to manipulate balances, duplicate transfers, or bypass spending limits. - **Customer Data Protection (PCI DSS)** — Cardholder data, personally identifiable information, and financial records must be protected in transit and at rest. - **API-Driven Architectures** — Open Banking APIs, payment integrations, and third-party fintech connectors expand the attack surface. Broken authentication and authorization in APIs are the leading cause of financial data breaches. - **Regulatory Compliance (SOC 2, PCI)** — SOC 2 Type II, PCI DSS, and state-level regulations require demonstrable security testing. - **Account Takeover Prevention** — Credential stuffing, session hijacking, and MFA bypass attacks target financial accounts directly. ### How We Help Financial Organizations - **Web Application Testing** — Deep manual testing of banking portals, trading platforms, and customer-facing financial applications. - **API Security Testing** — Comprehensive assessment of payment APIs, Open Banking integrations, and internal microservices. - **Mobile App Testing** — Security evaluation of iOS and Android banking apps, payment wallets, and trading platforms. - **Cloud Security Assessment** — Configuration review of AWS, Azure, or GCP environments hosting financial workloads. --- ## SaaS Penetration Testing URL: https://vokecyber.com/services/saas Secure your multi-tenant platform, protect customer data, and build the trust enterprise buyers demand. We test the attack paths that matter most to SaaS companies — tenant isolation, API abuse, privilege escalation, and authentication bypass. ### Security Challenges for SaaS Platforms - **Multi-Tenant Data Isolation** — One tenant accessing another tenant's data is a company-ending event. We test shared databases, storage layers, caching, and queue systems for cross-tenant data leakage. - **API Abuse Prevention** — SaaS platforms live and die by their APIs. We test for broken object-level authorization, mass assignment, rate limiting gaps, and injection attacks. - **Authentication & SSO Security** — Enterprise customers require SAML, OIDC, and SSO. We test your identity layer for misconfigured flows, token handling flaws, session management issues, and MFA bypass. - **Privilege Escalation Across Tenants** — Role hierarchies in SaaS platforms are complex. We test every privilege boundary for horizontal and vertical escalation. - **Insecure User Onboarding Flows** — Invitation links, self-service signups, trial accounts, and org creation flows are prime targets for account takeover and invitation hijacking. - **Third-Party Integration Security** — Webhooks, OAuth app integrations, marketplace connectors, and embedded widgets expand your attack surface. ### How We Help SaaS Companies - **Web Application Testing** — Deep testing of multi-tenant logic, role-based access controls, business logic, and data handling. - **API Security Testing** — Comprehensive assessment of REST and GraphQL endpoints against the OWASP API Security Top 10. - **Cloud Security Assessment** — Configuration review of AWS, Azure, or GCP infrastructure aligned with CIS Benchmarks. - **Mobile App Testing** — Security evaluation of iOS and Android companion apps. --- ## E-Commerce Penetration Testing URL: https://vokecyber.com/services/ecommerce Secure your online store, protect customer payment data, and prevent fraud. We help e-commerce businesses find and fix vulnerabilities in checkout flows, user accounts, and product management systems before attackers exploit them. ### Security Challenges in E-Commerce - **Payment Flow Vulnerabilities** — Checkout processes, payment gateway integrations, and tokenization systems are prime targets. Price manipulation, coupon abuse, and payment bypass attacks can result in direct financial loss. - **Account Takeover** — Credential stuffing, password reset flaws, and session hijacking allow attackers to access customer accounts, steal payment methods, and place fraudulent orders. - **Customer Data Exposure** — E-commerce platforms store names, addresses, payment details, and order histories. SQL injection, insecure APIs, and misconfigured databases can expose this data at scale. - **Business Logic Flaws** — Coupon stacking, inventory manipulation, price tampering, and discount abuse exploit flaws in how your application processes orders. These issues can't be found by automated scanners. - **Third-Party Integrations** — Payment processors, shipping APIs, inventory systems, and marketing tools create a complex supply chain. Each integration point is a potential entry for attackers. - **PCI DSS Compliance** — Any business that processes, stores, or transmits cardholder data must meet PCI DSS requirements, including regular penetration testing. ### How We Help E-Commerce Businesses - **Web Application Testing** — Deep manual testing of your storefront, admin panel, checkout flow, and customer account management. - **API Security Testing** — Assessment of product catalog APIs, order processing endpoints, payment integrations, and inventory management interfaces. - **Mobile App Testing** — Security evaluation of iOS and Android shopping apps. - **External Network Testing** — Black-box assessment of internet-facing infrastructure including web servers, CDN configurations, DNS, and email systems. --- ## Manufacturing Penetration Testing URL: https://vokecyber.com/services/manufacturing Protect your production environment, intellectual property, and supply chain systems. We help manufacturers identify and fix security vulnerabilities across IT networks, cloud-connected devices, and web applications before they lead to operational disruption. ### Security Challenges in Manufacturing - **IT/OT Convergence** — As manufacturing networks connect to corporate IT systems and the cloud, the attack surface expands. Poor segmentation between IT and OT environments allows attackers to pivot from email to the production floor. - **Ransomware Targeting** — Manufacturing is the most targeted industry for ransomware. Downtime directly impacts production output, making manufacturers more likely to pay ransoms. - **Intellectual Property Theft** — Trade secrets, product designs, and proprietary processes are valuable targets. Compromised file shares, weak access controls, and unencrypted communications put IP at risk. - **IoT & Connected Devices** — Smart sensors, PLCs, and connected equipment often run outdated firmware with minimal security controls. - **Cloud & ERP Security** — Cloud-hosted ERP systems, supply chain platforms, and inventory management tools are critical infrastructure. - **Supply Chain Risks** — Third-party vendor access, supplier portals, and remote maintenance connections create entry points. ### How We Help Manufacturers - **Internal Network Testing** — Assess network segmentation between IT and OT environments, identify lateral movement paths, and test Active Directory security. - **External Network Testing** — Black-box assessment of internet-facing infrastructure including VPN gateways, remote access systems, and exposed services. - **Web Application Testing** — Security assessment of supplier portals, customer ordering systems, inventory dashboards, and internal manufacturing web applications. - **Cloud Security Assessment** — Configuration review of AWS, Azure, or GCP environments hosting ERP systems, supply chain platforms, and manufacturing workloads. --- ## Education Penetration Testing URL: https://vokecyber.com/services/education Protect student records, secure learning platforms, and prevent unauthorized access to institutional systems. We help schools, universities, and EdTech companies find and fix vulnerabilities before they lead to data breaches or service disruption. ### Security Challenges in Education - **Student Data & FERPA Compliance** — Student education records, financial aid data, and personally identifiable information are protected under FERPA. A breach can trigger regulatory penalties, lawsuits, and loss of federal funding eligibility. - **Learning Management Systems** — LMS platforms like Canvas, Blackboard, and Moodle store grades, assignments, and student communications. Misconfigurations, weak access controls, and plugin vulnerabilities can expose this data. - **Large User Populations** — Thousands of students, faculty, and staff with varying access levels create a complex identity management challenge. - **Open Network Environments** — Campus Wi-Fi networks, BYOD policies, and guest access create a broad attack surface. - **Cloud & SaaS Sprawl** — Educational institutions adopt dozens of cloud services and SaaS tools across departments. Shadow IT and inconsistent security configurations create hidden vulnerabilities. - **Ransomware & Phishing** — K-12 schools and universities are heavily targeted by ransomware and phishing campaigns. ### How We Help Educational Institutions - **Web Application Testing** — Security assessment of student portals, enrollment systems, financial aid applications, and administrative dashboards. - **Network Penetration Testing** — Internal and external network assessments targeting campus networks, administrative systems, and research environments. - **API Security Testing** — Assessment of student information system APIs, LMS integrations, and third-party EdTech connectors. - **Cloud Security Assessment** — Configuration review of Google Workspace, Microsoft 365, AWS, or Azure environments. --- ## FAQ URL: https://vokecyber.com/faq ### About Penetration Testing **What is penetration testing?** Penetration testing (or pentesting) is a simulated cyber attack against your systems to identify security vulnerabilities before malicious hackers can exploit them. Our testers use the same techniques as real attackers to find weaknesses in your applications, networks, and infrastructure. **How long does a penetration test take?** The duration depends on the scope and complexity of the assessment. A typical web application test takes 3-5 days, while larger engagements involving multiple applications or network testing may take 1-2 weeks. We'll provide a detailed timeline during the scoping process. **Will testing impact our production systems?** We take a careful approach to minimize any impact on your systems. We coordinate timing with your team, avoid denial-of-service testing unless specifically requested, and maintain open communication throughout the engagement. Most tests have no noticeable impact on system performance. ### Process & Timeline **How quickly can you start testing?** Once contracts are signed and we have the necessary access, we can typically begin testing within 24 hours for most engagements. For larger or more complex assessments, we'll coordinate a start date that works for your team. **What's included in the final report?** Every report includes an executive summary for leadership, detailed technical findings with CVSS risk scores, proof-of-concept demonstrations, step-by-step remediation guidance, and prioritized recommendations. Reports are written in clear language that both technical and non-technical stakeholders can understand. **Is retesting included?** Yes! Every engagement includes a complimentary retest within 30 days of the final report. This gives your team time to implement fixes, and we'll validate that vulnerabilities have been properly remediated. ### Security & Expertise **What certifications do your testers hold?** Our testers hold industry-recognized certifications including OSCP (Offensive Security Certified Professional), OSWA (Offensive Security Web Assessor), CISSP, and CCSK. Each tester has a minimum of 5 years of hands-on offensive security experience. **How do you handle sensitive data discovered during testing?** We follow strict data handling protocols. Any sensitive data encountered during testing is documented only as necessary to demonstrate the vulnerability, never exfiltrated or stored beyond what's required for the report. All findings are encrypted and securely transmitted. **Do you sign NDAs?** Absolutely. We sign NDAs and have comprehensive confidentiality agreements as part of our standard engagement process. Your security findings and business information are always kept strictly confidential. --- ## Contact URL: https://vokecyber.com/contact - **Email**: info@vokecyber.com - **Phone**: (765) 422-5464 - **Location**: Based in the Charlotte, NC area — serving clients locally and nationwide. We respond to all inquiries within 24 hours during business days. --- ## Get Started URL: https://vokecyber.com/get-started Request a penetration testing quote by completing our scoping form. We'll provide a tailored proposal within 24 hours. The form collects contact information, service type selection, and service-specific scoping details. ### Available Services for Scoping - Web Application Assessment - Web API Assessment - LLM/AI Penetration Test - Mobile Application Assessment - External Penetration Test - Cloud Assessment - External Network Vulnerability Scan - PCI External Assessment - Phishing Simulation - IoT/Embedded Device Assessment - Thick Client Application Assessment - Red Team Assessment --- ## Company Details - **Company Name**: Voke Cyber - **Website**: https://vokecyber.com - **Email**: info@vokecyber.com - **Phone**: +1-765-422-5464 - **Address**: Charlotte, NC area, USA - **Hours**: Monday–Friday, 9:00 AM – 5:00 PM ET - **LinkedIn**: https://www.linkedin.com/company/vokecyber - **X (Twitter)**: https://x.com/vokecyber - **Founded by**: Louis Sanchez - **Service Area**: United States (nationwide), with focus on the greater Charlotte metro area --- ## Blog: Penetration Testing vs. Vulnerability Assessment: Which Does Your Business Need? URL: https://vokecyber.com/blog/penetration-testing-vs-vulnerability-assessment Author: Louis Sanchez | Published: February 25, 2026 | 8 min read ### The Quick Comparison | | Vulnerability Assessment | Penetration Test | |---|---|---| | Goal | Identify all known vulnerabilities | Exploit vulnerabilities to prove real-world impact | | Approach | Primarily automated scanning | Manual testing by a skilled human tester | | Depth vs. Breadth | Broad coverage, shallow depth | Focused depth, targeted exploitation | | Exploitation | No — identifies but doesn't exploit | Yes — safely exploits to demonstrate risk | | Business Logic Testing | No | Yes | | Typical Frequency | Monthly or quarterly | Annually or after major changes | | Duration | Hours to 1-2 days | 3-10+ days depending on scope | | Cost | Lower | Higher (reflects manual expertise) | | Output | List of vulnerabilities with severities | Detailed findings with proof-of-exploitation and attack narratives | ### What Is a Vulnerability Assessment? A vulnerability assessment is a systematic scan of your systems to identify known security weaknesses. It uses automated scanning tools that check your servers, applications, and network devices against databases of thousands of known vulnerabilities. Good at: Finding missing patches, identifying misconfigurations, cataloging known CVEs, providing broad coverage, supporting compliance like PCI DSS quarterly scans. Misses: Business logic flaws, chained attacks, context about mitigating controls, novel vulnerabilities, and frequently produces false positives. ### What Is a Penetration Test? A penetration test is a hands-on, manual security assessment where an experienced tester actively attempts to break into your systems using the same tools and techniques real attackers use, but in a controlled and authorized way. Good at: Proving real-world impact, finding business logic flaws, testing authentication and authorization, chaining vulnerabilities into significant attack paths, validating defenses under pressure. ### When You Need Each **Vulnerability Assessment**: Regular ongoing visibility, quarterly PCI DSS scans, establishing a baseline before a pentest, checking for obvious issues after infrastructure changes, scanning large numbers of assets quickly. **Penetration Test**: Launching a new application, compliance frameworks requiring it (PCI DSS, SOC 2, HIPAA), client/partner requirements, understanding real-world risk, finding deeper complex issues, testing specific attack scenarios. ### How They Work Together 1. Monthly or quarterly vulnerability scans for continuous visibility 2. Annual penetration testing for deeper issues scanners miss 3. Targeted penetration tests for new applications, major releases, or significant architectural changes **Key Takeaway**: Vulnerability assessments tell you what might be wrong. Penetration tests tell you what an attacker can actually do about it. You need both for a complete security picture. --- ## Blog: What Is Penetration Testing? A Plain-English Guide for Business Leaders URL: https://vokecyber.com/blog/what-is-penetration-testing Author: Louis Sanchez | Published: February 25, 2026 | 10 min read If you've been told your company needs a penetration test — or you've seen it mentioned in a compliance requirement — you're probably wondering what it actually involves. This guide breaks down what penetration testing is, how it works, what to expect from the process, and how to know if your organization needs one. ### The Short Version A penetration test (often called a "pentest") is a controlled, authorized simulation of a real cyber attack against your systems. A security professional — the penetration tester — attempts to find and exploit vulnerabilities in your applications, networks, or infrastructure using the same techniques that actual attackers use. The difference? It's done with your permission, on your schedule, and the goal is to find problems before a criminal does. **Key Takeaway**: Think of it like hiring someone to try to break into your building to test your locks, alarms, and security guards — except for your digital systems instead of your physical ones. ### How Is It Different from a Vulnerability Scan? A **vulnerability scan** is an automated tool that checks your systems against a database of known vulnerabilities. It's fast, broad, and relatively inexpensive — but it doesn't attempt to exploit anything and can't find logic flaws or complex attack chains. A **penetration test** goes much further. A human tester actively tries to exploit the vulnerabilities they find, chains together multiple weaknesses, tests business logic, and attempts to gain unauthorized access — just like a real attacker would. - **Vulnerability scan**: "Your front door lock is a model known to be pickable." - **Penetration test**: "I picked your front door lock, walked through your office, found the server room unlocked, and accessed your customer database." Both are valuable. Many organizations use vulnerability scans on a regular basis (monthly or quarterly) and conduct penetration tests annually or when significant changes are made. ### What Does a Penetration Test Actually Look Like? 1. **Scoping and Planning** — The tester works with you to define what's in scope: which systems, applications, or networks will be tested, what testing methods are allowed, and when testing will occur. 2. **Reconnaissance** — The tester gathers information about your systems, mapping your network, identifying technologies, discovering subdomains, and finding publicly available information. 3. **Testing and Exploitation** — The tester actively attempts to exploit vulnerabilities: bypassing authentication, escalating privileges, accessing unauthorized data, and chaining together smaller issues into larger attack paths. 4. **Reporting** — A detailed report including an executive summary, detailed technical findings with severity ratings, proof of exploitation, and step-by-step remediation guidance. 5. **Retesting** — After your team fixes the issues, the tester verifies that vulnerabilities have been properly remediated. Voke Cyber includes retesting at no additional cost within a 30-day window. ### Types of Penetration Testing - **Web Application Testing** — Tests websites and web apps for SQL injection, XSS, broken authentication, and insecure business logic. - **API Testing** — Evaluates the security of application programming interfaces. - **Network Testing (External)** — Tests internet-facing infrastructure from the outside. - **Network Testing (Internal)** — Simulates an attacker with internal network access. - **Mobile Application Testing** — Assesses iOS and Android apps for insecure data storage, weak authentication, and communication vulnerabilities. - **Cloud Security Assessment** — Reviews cloud environments (AWS, Azure, GCP) for misconfigurations. - **Red Team Assessment** — Full-scope adversary simulation testing people, processes, and technology together. ### Who Needs a Penetration Test? - **Compliance requirements** — PCI DSS, HIPAA, SOC 2, and many other frameworks require or strongly recommend regular penetration testing. - **Before a major launch** — Test new applications, products, or platforms before customers and attackers find the problems. - **After significant changes** — Major code changes, infrastructure migrations, or new integrations can introduce vulnerabilities. - **Annually at minimum** — Annual testing helps ensure security keeps pace with the evolving threat landscape. - **Client or partner requirements** — Many enterprise clients now require vendors to provide evidence of recent penetration testing. ### How to Prepare for a Penetration Test 1. Define what you want tested 2. Gather documentation (network diagrams, application architecture, user roles, API docs) 3. Set up test accounts with different permission levels 4. Notify your IT and security teams 5. Choose your timing ### What to Look for in a Provider - Manual testing, not just automated scanning - Experienced testers with recognized certifications (OSCP, OSWA, CISSP) - Direct communication with the person performing the test - Clear, actionable reporting useful to both executives and developers - Retesting included ### Common Misconceptions - **"We're too small to be a target."** — Small and mid-sized businesses are disproportionately targeted. Nearly half of all breaches affect small businesses. - **"We had a vulnerability scan, so we're good."** — Scans can't find business logic flaws, complex attack chains, or many vulnerabilities a skilled human tester will discover. - **"Penetration testing is too expensive."** — The cost is a fraction of what a data breach costs (average $4.44M per IBM's 2025 report). - **"It'll break our systems."** — Professional testers are careful and methodical, coordinating with your team. Most tests have zero impact on availability. --- ## Book a Call URL: https://vokecyber.com/book Schedule a free 15-minute intro call to discuss your penetration testing needs. No sales pitch, no pressure — just a straightforward conversation about your security needs. ### What to Expect - **Talk to the Tester** — You'll speak directly with the person who performs your assessment — not a sales rep. - **15-Minute Call** — Quick, focused conversation to understand your needs and determine the right approach. - **Custom Proposal** — After the call, you'll receive a tailored scope and quote within 24 hours. Prefer to skip the call? Fill out our scoping form at https://vokecyber.com/get-started and get a detailed proposal within 24 hours. --- ## Blog: When CVSS Scores the Endpoint, Not the Loss URL: https://vokecyber.com/blog/when-cvss-scores-the-endpoint-not-the-loss Author: Louis Sanchez — Voke Cyber | Published: August 17, 2026 Why the same vulnerability can honestly carry two very different CVSS scores, and what that means for triage. Worked example: Voke Cyber scored CVE-2026-16751 (Ente emergency-contact recovery bypass, a full account takeover) at 9.9 Critical with vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The published CVE record scores it 6.5 Medium with AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. The first four metrics are identical; everything downstream differs. Why the 6.5 is defensible: taken on its own terms, the vulnerable request reads nothing and destroys nothing. It flips one recovery session's status field from waiting to ready without authorization — an integrity impact and strictly nothing else. The photos, the Ente Auth 2FA seeds, and the victim lockout all arrive at the next step, a password reset that uses Ente's ordinary recovery flow working as designed, with a recovery key the attacker legitimately held from when they were genuinely added as an emergency contact. There is no second vulnerability to chain to, only a supported feature, so the conservative reading wins. CVSS scores the vulnerable component and the impact its compromise causes; answer that question honestly for this endpoint and the result is a Medium. Why the 6.5 is still misleading: C:N states that no data is exposed, but the sole purpose of the bypassed control was to prevent exposure. The waiting period existed to give the victim a chance to reject a recovery before a password reset. The chain is one HTTP request away, requires no unusual configuration, and uses documented functionality, so any attacker who performs step one performs step two. A metric describing the mechanism rather than the outcome sorts the bug into the wrong pile while being perfectly correct. Second data point: CVE-2026-17613 (Penpot cross-team file takeover) was re-scored from 9.9 Critical to 7.5 High on vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — availability only, for a bug where the attacker overwrites a victim's file and re-parents it into their own project, leaving themselves able to open, edit, export, and share it. The score captures the deprivation and misses the acquisition. Also covered: the Penpot enrichment record carried an SSVC assessment (exploitation proof-of-concept, technical impact partial, automatable yes) that was more actionable for a defender than the CVSS number, and is the field almost nobody pipes into a dashboard. Practical guidance: read the impact section rather than the badge; ask what the bypassed control was for, since the damage is whatever that safeguard prevented; re-score with environmental metrics because base metrics deliberately exclude your context; treat single-step chains as one finding when step two is documented functionality; and use SSVC decision-support fields to answer "do I care this week." Closes with why Voke Cyber publishes the assigned score on its advisories rather than its own: the CVE record is what the ecosystem consumes, a mismatched headline number reads as score inflation, and the argument is preserved by walking the assigned vector metric by metric while leaving the impact analysis intact underneath. --- ## Security Research: CVE-2026-96679 — Pre-Authentication Admin Takeover in Bisheng via /user/sso URL: https://vokecyber.com/research/cve-2026-96679-bisheng-preauth-admin-takeover Author: Louis Sanchez — Voke Cyber | Published: September 25, 2026 Three missing-authorization vulnerabilities found by Voke Cyber in Bisheng (dataelement/bisheng), an open-source, enterprise-grade LLM application and RAG workflow platform from DataElem, Inc., typically self-hosted on Kubernetes or Docker for multi-tenant, multi-team use. Coordinated through CERT/CC as VU#166125. CVE-2026-96679 — SSO pre-auth admin takeover — CVSS v3.1 base score 9.8 Critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-306/CWE-287/CWE-290, GHSA-c2hq-p2mh-q26r. CVE-2026-96681 — cross-user flow/workflow version IDOR — CVSS 6.5 Medium, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-862/CWE-639/CWE-200, GHSA-5cc6-8jr6-7xfw. CVE-2026-100156 — cross-user assistant LLM credential abuse — CVSS 5.4 Medium, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L, CWE-862, GHSA-3pg6-86c3-3jv5. Root cause of the critical: Bisheng Pro is designed to sit behind a separate, closed-source SSO gateway. To support that, the open-source backend exposes POST /user/sso (src/backend/bisheng/user/api/user.py), which accepts a username and returns a signed session token for that user. The only gate on the endpoint is a check that BISHENG_PRO is enabled — an environment-variable flag, not a credential. There is no shared secret, no signed assertion, no header token, and no IP allowlist verifying the caller actually is the trusted gateway rather than an anonymous visitor. With the flag on, the endpoint issues a token for whatever username it is handed, and the account-provisioning logic behind it will, under ordinary first-user or configured-admin-name conditions, create and return that session at the super-admin role with no password and no prior authentication. A single unauthenticated request can therefore return a fully privileged administrative token; even a non-admin username yields an unauthenticated account-creation primitive. Impact of the critical: full control of the instance — read every user's flows, workflows, assistants, knowledge bases, and every configured LLM-provider API key (Confidentiality High); create, modify, or delete any user, flow, assistant, knowledge base, or system setting (Integrity High); delete administrators, lock out users, wipe knowledge bases (Availability High). Because Bisheng flow and assistant configs routinely embed credentials for external systems, admin compromise typically chains outward into connected infrastructure. Pre-conditions: BISHENG_PRO=true and network reachability to /user/sso; default open-source instances ship with BISHENG_PRO=false, where the issue is dormant. The other two share one pattern: a read or execute path that skips the ownership check its sibling write paths in the same class already enforce. CVE-2026-96681 — the flow/workflow version list and version-info read methods (src/backend/bisheng/api/services/flow.py) never check the caller against the requested flow, and the list path additionally returns soft-deleted versions; a version definition exposes REST/SQL/GraphQL node configs (frequently including hardcoded credentials), proprietary system prompts, and tool/flow/knowledge-base linkages, readable by any authenticated default-role account given a flow or version id. CVE-2026-100156 — the assistant prompt auto-optimization path (auto_update_stream in assistant.py) takes an assistant id from the caller and never checks ownership before running the optimization against that assistant's configured LLM, letting an attacker drive inference billed to another user's provider account and receive the victim assistant's tool/flow configuration in the stream. Patch status verified 2026-09-25 by reading upstream source directly (not changelogs). CVE-2026-96679: no fixed release; the legacy /user/sso endpoint is unchanged and still live at main HEAD. The vendor has built a properly HMAC-authenticated replacement family (/api/v1/internal/sso/login-sync) and the legacy handler's docstring points to it, but the old unauthenticated endpoint has not been removed, disabled, or gated — no 2.x or 3.x release remediates it. CVE-2026-96681: fixed only in the v3.0.0 line (first present at v3.0.0-beta1) as part of a migration to a relationship-based (ReBAC) permission model; every 2.x release, including the latest 2.6.0 patch tag, remains vulnerable. CVE-2026-100156: fixed in v2.5.0 — but the fix commit predates both discovery (2026-05-14) and the report (2026-05-23), incidental collateral from the same permission-architecture refactor rather than a response to disclosure, never documented as a security fix. Mitigation for the unpatched critical, since no fixed version exists: do not set BISHENG_PRO=true unless the deployment is genuinely fronted by a gateway that authenticates callers before they reach /user/sso; migrate to the HMAC-authenticated /api/v1/internal/sso/login-sync endpoints; and as defense in depth, bind /user/sso to the gateway path only. The proof-of-concept request is withheld until a fix ships. Disclosure: reported to DataElem via GitHub Private Vulnerability Reporting on 2026-05-23 (no SECURITY.md or security contact existed); 26+ days of vendor silence led to CERT/CC coordination (case opened 2026-07-28), a CERT-initiated advisory on 2026-08-19, and CVE assignment across September 2026. Found and disclosed by Louis Sanchez / Voke Cyber via CERT/CC. The narrative writeup is at https://vokecyber.com/blog/cve-2026-96679-bisheng-preauth-admin-takeover. --- ## Blog: One Request to Admin: Three Skipped Auth Checks in Bisheng URL: https://vokecyber.com/blog/cve-2026-96679-bisheng-preauth-admin-takeover Author: Louis Sanchez — Voke Cyber | Published: September 25, 2026 The story behind three missing-authorization flaws in Bisheng, the open-source enterprise LLM platform. The theme is that they are the same mistake made three times, in three different modules, by developers who plainly knew better: a function that reads or acts on a specific user's data skips the ownership check that its sibling functions, sitting right next to it in the same class, already perform. The write paths were guarded; the read and execute paths were not. The critical (CVE-2026-96679, CVSS 9.8) is worse than an IDOR because it needs no account at all. Bisheng Pro is meant to sit behind a closed-source SSO gateway, and the backend's /user/sso endpoint issues a signed token for a supplied username — but the only thing gating it is a check that the BISHENG_PRO environment flag is on. A flag is not a credential: the code assumes a trusted gateway is present rather than verifying the caller is one, so one unauthenticated request returns a super-admin token. It remains unpatched — the vendor built an HMAC-authenticated replacement but never removed or gated the legacy endpoint — so the post withholds the proof-of-concept request and gives operators the root cause and mitigations instead (only enable Pro behind an authenticating gateway; move to /api/v1/internal/sso/login-sync; restrict the legacy endpoint to the gateway path). The other two are cross-user leaks. CVE-2026-96681 (6.5) lets any logged-in user read any other user's flow or workflow version, including the hardcoded credentials and proprietary system prompts inside node configs, and even soft-deleted versions the owner thought were retracted — fixed only in the v3.0.0 line, so every 2.x release stays vulnerable. CVE-2026-100156 (5.4) let any user run prompt-optimization against another user's assistant, spending that victim's LLM API budget and leaking their tool and flow configuration — fixed in v2.5.0, but silently and before disclosure, folded into an unrelated refactor and never called out as a security fix. Cross-cutting lessons: a feature flag is not authentication; the fastest way to find a missing authorization check is to line up every method that touches the same resource and look for the odd one out, which takes an afternoon and would have caught all three; and the severity irony that the highest-severity bug is the one still unpatched while the two lower-severity ones got fixed essentially by accident. The disclosure story: no vendor SECURITY.md, private reports unanswered for 26+ days, and coordination through CERT/CC (VU#166125), which opened its own advisory after continued vendor silence. Found and disclosed by Voke Cyber. --- ## Security Research: Stored XSS in Trilium's Share Renderer via Iframe src Attribute Breakout URL: https://vokecyber.com/research/trilium-share-renderer-stored-xss Author: Louis Sanchez — Voke Cyber | Published: September 13, 2026 A stored cross-site scripting vulnerability (CWE-79 Stored XSS, CWE-116 Improper Encoding or Escaping of Output) found by Voke Cyber in Trilium (developed under the TriliumNext org), an open-source, self-hosted hierarchical note-taking application with roughly 38,000 GitHub stars. CVE-2026-91021, GHSA-7c7g-7c3p-v53w. CVSS v3.1 base score 8.7 High, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N — matching the score GitHub's own advisory calculator publishes for the same vector. Affected: all versions through v0.104.1. Fixed in v0.105.0, released 2026-08-19. Root cause: a Trilium note of type "Web View" renders as an iframe pointed at a URL held in the note's #webViewSrc label. Trilium's share feature publishes notes (and subtrees of notes) as public or credentialed web pages, and the share renderer (apps/server/src/share/content_renderer.ts, function renderWebView) built that iframe's HTML by interpolating the label's value directly into the src="..." attribute after passing it through sanitize.sanitizeUrl, a wrapper around the @braintree/sanitize-url library. That library normalizes dangerous URL schemes (javascript:, data:, vbscript: all become about:blank) but is not an HTML escaper: for an absolute http(s) URL it parses with new URL(), which happens to percent-encode a literal quote, but for a relative path or any other scheme (mailto:, ftp:, wss:) it returns the input string verbatim, embedded double quotes included. A note owner who sets the label to a value such as `./a" onload="alert(document.domain)" data-x="` gets it echoed byte-for-byte into the iframe tag, closing the src attribute early and adding an arbitrary onload attribute the browser executes on render. The result is emitted into the page template via an EJS `<%- content %>` tag that is unescaped by design, since content is assumed to already be safe markup by that point. Impact: any visitor to the resulting public or credentialed share — an anonymous visitor, a colleague sent the link, or an authenticated administrator auditing what got published — executes the attacker's JavaScript on the Trilium share origin, the same origin serving /api/*, /login, and /api/script/exec. The script can read and exfiltrate the visitor's session cookie, or skip that step and issue authenticated fetch() calls with credentials directly. Where the visitor is an administrator, this reaches POST /api/script/exec, which runs a Trilium script note as server-side Node.js — turning one shared note into full remote code execution on the host the moment the right visitor opens it. The fix, shipped the same day the report was accepted (2026-08-03) in two commits: b139677e3 ("fix(share): keep a web view source URL inside the src attribute") rebuilds the iframe as a real DOM element via node-html-parser and sets the source through setAttribute(), which escapes automatically and closes off the injection entirely; cbae79bfa ("fix(share): only frame an absolute http(s) web view source") adds defense in depth by rejecting any source that is not an absolute http/https URL before a frame is built at all, since that is the only kind of value the Web View setup form was ever meant to produce. Both commits shipped in v0.105.0 (2026-08-19). Operational note: after upgrading, an existing Web View note whose #webViewSrc is a relative path or a non-http(s) scheme will stop rendering and log a server-side error rather than silently keep working — operators relying on such a value need to update it. CVE-2026-91021 was assigned by CERT/CC on 2026-09-14, one day after the advisory published, and its CVE record cites this advisory as its reference. GitHub had separately requested a CVE on 2026-08-03 (the same day the report was accepted) and again roughly three weeks later, after the reporter followed up; the maintainer explained the advisory would publish once the fixed release reached 30 days old. Reported 2026-07-02 through GitHub's private security advisory process, in scope under Trilium's SECURITY.md as XSS affecting other users. Found and disclosed by Voke Cyber, reported directly to TriliumNext via GitHub. The narrative writeup is at https://vokecyber.com/blog/trilium-share-renderer-stored-xss. --- ## Blog: Trilium's Share Renderer Had a Quoting Bug, and It Was Enough for Remote Code Execution URL: https://vokecyber.com/blog/trilium-share-renderer-stored-xss Author: Louis Sanchez — Voke Cyber | Published: September 13, 2026 The story behind the Trilium share-renderer stored XSS. Most stored XSS write-ups involve a sanitizer nobody added; this one involves a sanitizer that was already there and simply was not built for the job it was handed. Trilium's share renderer ran a Web View note's source URL through a URL sanitizer before dropping it into an iframe's src attribute — the sanitizer's real job is blocking dangerous schemes like javascript:, and it does that correctly. It was never an HTML escaper, and for a relative path or a non-http(s) URL it hands the value back untouched, quotes included. A note label ending in a quote and an onload attribute closes the src attribute early and adds new markup the page's author never wrote; the browser parses the result as five separate attributes on one element rather than one attribute with a strange value. Covers why the two guarantees sound identical but are not: "strips dangerous schemes" and "safe to place inside an HTML attribute" are different contracts, and the library's own documentation only ever promised the first one. Walks through the exact proof of concept (a relative-path label ending in `" onload="alert(document.domain)" data-x="`), and why the blast radius reaches further than a typical stored XSS: the Trilium share origin also serves /api/script/exec, which runs a script note as server-side Node.js, so an administrator opening a malicious share during routine review hands the attacker code execution on the host — one quote character, three steps, full server compromise. Also covers why the maintainer's fix shipped as two separate commits rather than one: the first (building the iframe as a real DOM element and setting its source via setAttribute(), which escapes automatically) closes this exact bug, while the second (refusing to render any source that is not an absolute http(s) URL) closes the entire class of "an unexpected value reached this label by some route other than the setup form," so the next unexpected input doesn't produce an XSS either. Both landed the same day the report was accepted, shipped in v0.105.0. Discusses the disclosure timeline: reported 2026-07-02, fixed 2026-08-03, released 2026-08-19, and published 2026-09-13 — Trilium's practice is to let a release age roughly a month before making the underlying issue public, so operators get a real update window before the technical details are out. CVE-2026-91021 was assigned by CERT/CC the day after publication, citing this advisory as its reference. Found and disclosed by Voke Cyber. --- ## Security Research: Leantime JSON-RPC Account Takeover via editOwn URL: https://vokecyber.com/research/leantime-jsonrpc-editown-account-takeover Author: Louis Sanchez — Voke Cyber | Published: August 18, 2026 An authorization bypass (CWE-639 Authorization Bypass Through User-Controlled Key, CWE-862 Missing Authorization) found by Voke Cyber in Leantime, a self-hosted open-source project management platform (PHP/Laravel) used for projects, tickets, timesheets, and client work. CERT/CC coordination case VU#685483. The original private report GHSA-jxgw-q79v-g84j was closed by the maintainer without substantive review; Voke Cyber subsequently opened GHSA-5447-phq9-qjmm. Both GitHub advisories and the CERT/CC note remain non-public as of 2026-08-18. CVSS v3.1 base score 8.8 High, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, rising to 9.8 (PR:N) on instances with self-registration enabled. Affected: Leantime 3.x through v3.8.0. Fixed in v3.9.0, released 2026-06-12, merged 2026-06-02 in PR #3471. Assigned CVE-2026-76647, published by CERT/CC on 2026-08-19 under VU#685483; the CVE record cites both Voke Cyber write-ups as references. Root cause: Leantime exposes its internal service layer over a JSON-RPC endpoint at POST /api/jsonrpc. The browser-facing controller app/Domain/Users/Controllers/EditOwn.php pins the edited record to the session by reading the user id out of session data and ignoring client input, which is correct. The JSON-RPC dispatcher never touches that controller: app/Domain/Api/Controllers/Jsonrpc.php resolves the service out of the container and invokes the method with the request body parameters, with no authorization check before the call and not even a check that the method was intended to be exposed over the API — the maintainer's own TODO comment about checking method attributes sits twenty-four lines above the dispatch. The caller-supplied id therefore reaches the Users service editOwn method untouched, which passes it to the repository, which writes the zp_user row named by that id and hashes and stores a new password whenever one is supplied. Nothing between the socket and the WHERE clause asks whether the caller owns that row. Exploitation: any valid login is sufficient — a self-registered account, an invited client, or a read-only teammate. Authenticate normally, keep the session cookie, and send a single JSON-RPC call to method leantime.rpc.users.users.editOwn with the id parameter set to the victim's user id (1 is the instance owner in a default install) and a chosen password in the values object. Then log in through the ordinary login form. Setting the user field to the victim's existing email keeps the account reachable at the address the attacker already knows, making the takeover quiet; sending a different value rewrites the victim's login email as well. The password field is optional — omitting it yields an arbitrary cross-account profile rewrite, and including it is what turns a profile edit into a credential takeover. Impact: from any authenticated account including the lowest-privilege role, an attacker can set a known password on any other account including administrators and the instance owner and log in as them, lock the legitimate user out by rewriting login email and password together, and inherit everything the taken-over account reaches — all projects and clients, files, timesheets, user management, and instance settings. Because the owner is reachable from a read-only login, the instance authorization model does not degrade gracefully; it collapses in one request. Generalizable lesson: when an application exposes its service layer over RPC, every authorization check that lives in a controller stops being a control. The controller was the only thing pinning editOwn to the session, and an RPC dispatcher routes around controllers by design. Self-service methods (editOwn, updateMyProfile, changeMyPassword) are hit hardest because they are written under the assumption that the id was never attacker-controlled. The correct fix is authorization in the service or the dispatcher, never only in the controller. Remediation: upgrade to v3.9.0 or later, where the service method discards the caller-supplied id and pins the write to the session user. There is no configuration workaround on affected versions short of blocking the method at a reverse proxy, because the endpoint does not distinguish a self-edit from a cross-account edit before it writes. Operators who ran an affected version with untrusted or self-registered accounts should treat it as a credential-compromise event: audit zp_user for unexpected modified timestamps and changed usernames, review admin membership, and force a password reset. The same release also introduced a permission engine across the service layer, so authorization no longer depends on which entry point a request came through, which is the structurally correct place for it. The fix was shipped silently: PR #3471 is titled after a refactor, no security advisory accompanied it, and the release notes do not name the issue. Identifiers: this finding is distinct from the four Leantime JSON-RPC issues published as CVEs by third parties in July 2026 — CVE-2026-59712 (getUser credential disclosure), CVE-2026-15509 (addUser and editUser role escalation), CVE-2026-15510 (saveSetting), and CVE-2026-59713 (OIDC login CSRF). It is a different method, weakness class, and outcome, and is not described by any of them. The v3.9.0 release notes name several IDOR fixes; the self-service password overwrite is not one of them. The narrative writeup is at https://vokecyber.com/blog/leantime-jsonrpc-editown-account-takeover. --- ## Blog: The Profile Method That Would Edit Anyone: An IDOR in Leantime's JSON-RPC URL: https://vokecyber.com/blog/leantime-jsonrpc-editown-account-takeover Author: Louis Sanchez — Voke Cyber | Published: August 18, 2026 The story behind the Leantime editOwn account takeover. A function named editOwn tells you what it is for, which is exactly why it is worth examining: it was safe through the browser and wide open over the API, not because it was written twice but because the one thing making it safe was not part of the method at all. The controller read the user id from the session and ignored client input; the JSON-RPC dispatcher called the same service directly with the request body, so the id became just a number in some JSON chosen by whoever sent the request. One call naming user id 1 with a chosen password, then a normal login, and the instance is yours — from a read-only or self-registered account, with no chaining, no race, and no victim interaction. The central lesson: a lot of applications put authorization in controllers, which is natural because that is where the request arrives and the session is available. Then somebody adds an RPC or GraphQL surface over the existing service layer because API clients need the same functionality, which is a reasonable engineering decision — and in that moment every authorization check living in a controller quietly stops being a control. Not removed, not weakened, just bypassed by a route that does not pass through where the checks live. The services were never the security boundary; they were the thing behind it. The question to ask is not whether the services are tested but which authorization checks live in controllers and whether the RPC path goes through them. Also covers the disclosure outcome and why it matters: reported in April, no vendor reply after the stated 48-hour window, CERT/CC case opened in May, and fixed in June inside a feature pull request about rolling a new permission engine across the Users domain, with no security advisory. Four adjacent Leantime JSON-RPC CVEs were published by other researchers in July; this one is not among them. Silent patching is a bad practice rather than a cautious one. Attackers read commit diffs, so a public repository publishes the exploit the moment the fix merges - a diff adding an ownership check to a self-service method tells a competent reader exactly what was wrong and how to exploit the prior version. Defenders are the only party relying on being told, so the outcome inverts the intent: the exploit is public in the diff and the warning is not. A patched bug with no identifier is invisible to the people who most need it — a small team self-hosting a project tool learns about upgrades from CVE feeds, Dependabot alerts, and release notes that say "security fix," and an account-takeover path closed inside a refactor-titled pull request produces none of those. The code being fixed and the knowledge being distributed are different things, and only one of them protects anybody. A carve-out CVE has been requested through CERT/CC. --- ## Security Research: CVE-2026-16772 — Privilege Escalation to Admin in Akaunting via Self-Service Profile Update URL: https://vokecyber.com/research/cve-2026-16772-akaunting-privilege-escalation Author: Louis Sanchez — Voke Cyber | Published: August 14, 2026 CVE-2026-16772 is a privilege escalation (CWE-862 Missing Authorization, CWE-269 Improper Privilege Management) found by Voke Cyber in Akaunting, a popular open-source accounting and invoicing platform used by small businesses to manage invoices, bills, customer and vendor records, bank details, and reports, typically with several staff each holding a limited role. CERT/CC coordination case VU#737420. CVSS v3.1 base score 8.1 High, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. Affected: Akaunting through 3.1.21. Fixed in 3.2.0, released 2026-07-12 in commit 80ef6d3b154a. The fix shipped a month before the CVE published and carried no vendor advisory, so the CVE record still lists no patched version. Root cause: when a user updates their own profile, Akaunting dispatches an update job that saves the submitted fields, and the set of roles is among them. In app/Jobs/Auth/UpdateUser.php, handle() applies the roles with a single unconditional call — if the request has a roles key, the user's roles are synchronized to exactly what the form contained. There is no authorization check on that path. The job's own authorize() method only blocks a user from disabling themselves plus an orphan-company edge case; it never asks whether the caller is permitted to manage roles. The web controller that dispatches the job, app/Http/Controllers/Auth/Users.php, deliberately allows a user to update their own record, so a user editing themselves passes the id-equality branch and reaches the job. The action is reachable by anyone holding the default update-auth-profile permission, which the seeded manager and accountant roles both carry. Exploitation: the attacker needs any authenticated Akaunting account with the ordinary self-service profile permission. They submit their own profile-update form with the administrator role ID added to the roles field, and the server applies it. No chaining, no token abuse, no timing — the escalation is the intended code path running without the check that should have guarded it. Scope boundary: the JSON API endpoints that manage users are correctly permission-gated, because the API user controller inherits update-auth-users and delete-auth-users middleware from its base controller. A broader cross-tenant variant through the API was investigated and ruled out for exactly that reason. The finding is scoped to the confirmed web self-update privilege escalation. Impact: full administrator control of the installation from the most basic staff account. That means reading every financial record, altering or deleting invoices and bills, creating and paying bills, managing users, and changing company settings. The threat model is not an outside attacker or an existing admin — it is any employee, contractor, or limited accountant who was given a login. Remediation: no vendor fix at publication; reported to the vendor 2026-05-20 with no response, then coordinated through CERT/CC (VU#737420). Interim mitigations: audit which accounts currently hold the administrator role, treat every account with the default self-service profile permission as able to promote itself, and monitor profile-update requests that carry a roles field. Correct code fix: gate the role synchronization on a permission to assign roles, so that updating your own profile and assigning your own roles no longer share a code path. The narrative writeup is at https://vokecyber.com/blog/cve-2026-16772-akaunting-privilege-escalation. --- ## Blog: The Profile Page That Handed Out Admin: CVE-2026-16772 in Akaunting URL: https://vokecyber.com/blog/cve-2026-16772-akaunting-privilege-escalation Author: Louis Sanchez — Voke Cyber | Published: August 14, 2026 The story behind CVE-2026-16772 in Akaunting. Most privilege-escalation bugs make you work for it — chain a file write into code execution, abuse a token that was never meant to leave one screen, find the admin endpoint that forgot its middleware. This one asks for none of that: you open your own profile, add the admin role to the form, and save. The update job takes the submitted role list at its word, because "edit your own record" and "assign your own roles" went through the same door, and the permission to do the first was quietly treated as permission to do the second. Covers the sibling that got it right — Akaunting's JSON API gates the same operation correctly by inheriting update-auth-users from its base controller, so the knowledge of how to check was already in the codebase, already applied, one controller over; it just was not applied on the path an ordinary user actually reaches by clicking "Edit profile." Also covers why "just an accountant" is the whole point (the severity lives entirely in who can do it, and nearly every user in an Akaunting company holds the required permission by default), and why the finding was scoped down: a cross-tenant API variant was chased and did not hold, precisely because the API path does its check — scoping to what can be proven is the difference between a report someone can act on and one they have to fact-check. CVSS 8.1 High, fixed in 3.2.0, disclosed via CERT/CC (VU#737420). Found and disclosed by Voke Cyber. --- ## Security Research: CVE-2026-17613 — Cross-Team File Takeover in Penpot via import-binfile URL: https://vokecyber.com/research/cve-2026-17613-penpot-cross-team-file-takeover Author: Louis Sanchez — Voke Cyber | Published: August 4, 2026 CVE-2026-17613 is a cross-team file takeover (CWE-639 Authorization Bypass Through User-Controlled Key, CWE-862 Missing Authorization) found by Voke Cyber in Penpot, the widely used open-source design and prototyping platform (Kaleidos) that serves as the open alternative to Figma, run both as Penpot Cloud and self-hosted by tens of thousands of teams. GitHub Security Advisory GHSA-8qqw-wm58-45v7; CERT/CC coordination case VU#241166. CVSS v3.1 base score 7.5 High, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — scored against the default open-self-registration deployment; where sign-up is closed the attacker needs a granted account (PR:L) and the score drops to 6.5. Affected: Penpot from v1.20 onward, self-hosted Community Edition and Penpot Cloud. No fix available at publication. Root cause: the import-binfile RPC command accepts an optional caller-supplied file-id meaning "import into this existing file instead of creating a new one" (an in-place import). The handler validates edit permission on the caller's project-id — a project the caller obviously owns, since they supplied it — but the caller-supplied file-id is bound straight through and used with no permission check. The adjacent export-binfile command in the same source file validates read permission on its file-id correctly; the permission function exists and is already imported into that namespace. The import path simply omits the call. The in-place import then fetches the target file by id alone with no ownership predicate, enables overwrite mode, writes attacker content into the victim's file row, and sets the file's project to the attacker's project, with the final database update keyed only on the attacker-supplied file id. Why it is takeover rather than vandalism: Penpot resolves file permissions by walking from the file to its project to its team. Rewriting the project pointer means the attacker does not bypass the permission model, they satisfy it — every other endpoint then agrees the file is theirs. The victim's file vanishes from their project, appears in the attacker's, and can be opened, edited, exported, duplicated, and shared. The victim cannot reach the file at all, so there is no in-product restore path. Attack: prerequisite is any authenticated account with its own project; on a default install the attacker can self-register. File ids are UUIDs and not guessable, but they leak through ordinary use: (1) public share links put the file id in the URL in plaintext, and those are sent to clients and coworkers constantly; (2) any user who has linked a shared design-system library can read that library file's id from a normal library-listing call, with no error and no trace — the route that reaches an entire organization's design system rather than one file; (3) workspace and viewer URLs embed the file id, so it appears in screenshots, support tickets, Slack pastes, and screen shares. With an id in hand the attack is a single import call: project-id set to a project the attacker owns, file-id set to the victim's file, and a valid single-file .penpot archive as the payload. Attack complexity rationale: CERT/CC raised whether the unguessable file id should make this AC:H. It stays AC:L because High complexity is meant for conditions the attacker cannot arrange on their own (race windows, memory layout, independent victim action). Receiving a share link and listing shared libraries are ordinary unilateral actions any account can take at any time. Impact: data destruction (victim file contents overwritten); persistent takeover (file re-parented to the attacker's team); library poisoning (if the hijacked file was a shared library, every dependent file across every other team pulls attacker-controlled colors, components, and typography on next sync); cross-team scope change (the resource moves entirely out of the victim team's security boundary). A related lower-severity issue reported alongside it: the real-time WebSocket channel lets a client subscribe to a file or team topic using a client-supplied id with no permission check, allowing live exfiltration of collaborative edits and shared-library changes for any file whose id the attacker knows. Same root pattern; one patch closes both. Remediation: no vendor fix at publication; re-verified live at develop HEAD on 2026-07-27. Interim mitigations: disable open self-registration (removes the sign-up-and-attack path, 7.5 down to 6.5); treat every account on the instance as having write access to every file on it, and consider separate instances for genuinely sensitive client work if you rely on team separation for confidentiality; audit for file rows whose owning project changed without a corresponding user action and for edits written by a profile that is not a member of the file's team (an in-place import leaves no normal change row, so mismatched project lineage is the signal); keep export-binfile snapshots outside Penpot, since in-product recovery is unavailable to a victim who has lost access. Correct code fix: require edit permission on the supplied file-id for in-place imports, and separately reject any in-place import that would move the file into a different project than the one it currently belongs to — the second assertion blocks the re-parenting leg on its own. Disclosure: reported to the vendor 2026-05-28 via GitHub's advisory process and the published security contact; no response after 21 days; reported to CERT/CC 2026-06-18; CVE assigned and VU#241166 opened 2026-07-06; public disclosure 2026-08-04 without a fix. The drop-in exploit script and payload recipe are withheld until a fixed release ships. The narrative writeup is at https://vokecyber.com/blog/cve-2026-17613-penpot-cross-team-file-takeover. --- ## Blog: ISO 27001 Security Testing Requirements: What Auditors Expect URL: https://vokecyber.com/blog/iso-27001-security-testing-requirements ISO/IEC 27001:2022 does not name penetration testing directly, but three Annex A controls make it a practical necessity: A.8.8 (Management of Technical Vulnerabilities — obtain vulnerability information, evaluate exposure, take appropriate measures), A.8.34 (Protection of Information Systems During Audit Testing — acknowledges technical testing of live systems as expected ISMS activity), and A.5.36 (Compliance with Policies, Rules and Standards for Information Security — verifying security policies are actually followed). Auditors want a penetration test report dated within the last 12 months, referencing a recognized methodology (OWASP, PTES, OSSTMM, or NIST SP 800-115), with documented remediation and retesting evidence. ### Certification Structure Annex A contains 93 controls across four 2022-revision themes: Organizational, People, Physical, and Technological. Certification runs a two-stage audit by an accredited certification body (Stage 1 documentation review, Stage 2 implementation verification), followed by annual surveillance audits and full recertification every three years. ### Testing Scope and Frequency Testing scope must match ISMS scope and the Statement of Applicability (SoA) — a pentest that covers the main web application while ignoring in-scope infrastructure, APIs, or cloud environments is one of the most common gaps that produces a nonconformity at surveillance audit. Minimum cadence is annual, plus retesting after significant changes (Clause 6.3, "Planning of changes," new in the 2022 revision) and before the three-year recertification audit. ### Findings Feed Risk Management Pentest findings are inputs to the ISO 27001 risk process, not standalone technical issues: finding identified, risk assessed via the org's methodology, risk treated (mitigate/accept/transfer/avoid) and documented, treatment implemented and retested, results presented at management review (Clause 9.3). Clause 10.1 requires continual improvement of the ISMS — auditors compare year-over-year pentest results expecting a shrinking, evolving finding set, not the same unresolved issues on repeat. --- ## Blog: HIPAA and Penetration Testing: What's Required Now, and What's About to Be URL: https://vokecyber.com/blog/hipaa-penetration-testing-requirements The current HIPAA Security Rule (45 CFR §§ 164.302–318) does not explicitly mandate penetration testing, but two administrative safeguards effectively require testing evidence: the risk analysis requirement (§ 164.308(a)(1)(ii)(A) — an accurate and thorough assessment of risks and vulnerabilities to ePHI) and the evaluation requirement (§ 164.308(a)(8) — a periodic technical and nontechnical evaluation). NIST SP 800-66 Rev. 2 names penetration testing as an activity supporting the evaluation requirement, and the most common finding in OCR enforcement actions is a risk analysis that was not accurate or thorough. ### The Proposed Security Rule Update The January 2025 NPRM (comment period closed March 2025; not final as of August 2026, with the regulatory agenda targeting 2027) would require: penetration testing at least every 12 months by a qualified person; vulnerability scanning at least every 6 months; encryption of ePHI at rest and in transit; multi-factor authentication; network segmentation, asset inventory, and a network map; and 72-hour restoration of critical systems. It removes the addressable/required distinction and applies to covered entities and business associates alike, with no small-organization carve-out. ### What a HIPAA-Aligned Pentest Covers Scope follows the ePHI: patient-facing web applications (portal authorization testing), APIs (FHIR endpoints, mobile backends, integration interfaces), external network, internal network (lateral movement and segmentation between clinical and business networks), and cloud environments. Reports should map findings to Security Rule safeguards and document remediation and retesting. Test at least annually and after significant environmental or operational changes. --- ## Blog: The Import That Took the File With It: CVE-2026-17613 in Penpot URL: https://vokecyber.com/blog/cve-2026-17613-penpot-cross-team-file-takeover Author: Louis Sanchez — Voke Cyber | Published: August 4, 2026 The story behind CVE-2026-17613 in Penpot. Most access-control bugs let an attacker touch something that is not theirs; this one moves the file into the attacker's account on the way out. The import API checks the project you own and never checks the file id you supplied, and because the in-place import also rewrites the file's owning project, the attacker does not bypass Penpot's file→project→team permission walk — they satisfy it. Covers why "file ids are random" is not a defense (share links, shared-library listing, workspace URLs), why attack complexity stays Low (AC:H is for conditions the attacker cannot arrange unilaterally, not for "the attacker has to do a normal thing first"), and the operator guidance in the absence of a patch. The lesson: the correct permission check exists on the adjacent export path, written by the same people in the same file for the same resource — which proves the knowledge was there and simply was not applied on both paths. Symmetric features (import/export, create/update, single-record/bulk, read/write) should be reviewed as pairs, because the presence of the right check nearby is not evidence the check is everywhere. CVSS 7.5, no patch, disclosed via CERT/CC (VU#241166). Found and disclosed by Voke Cyber. --- ## Security Research: CVE-2026-16751 — Account Takeover in Ente via Emergency-Contact Recovery Bypass URL: https://vokecyber.com/research/cve-2026-16751-ente-emergency-recovery-bypass Author: Louis Sanchez — Voke Cyber | Published: July 26, 2026 An authorization bypass (CWE-639 primary, CWE-863) found by Voke Cyber in Ente, a privacy-first, end-to-end encrypted service for photos, authentication codes (Ente Auth), and passwords/secrets (Ente Locker). CVE-2026-16751; GitHub Security Advisory GHSA-9jcx-2fcp-hxmf; CERT/CC coordination case VU#834187. CVSS v3.1 base score 6.5 Medium, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. Feature context: Ente lets a user nominate an emergency contact who can help recover the account if locked out. During setup the user's recovery key is deliberately wrapped to the contact's public key. Because that is a break-glass capability, a recovery started by an emergency contact enters a waiting period (commonly 30 days, configurable up to 60) during which the account owner is emailed and can reject it. The waiting period is the entire safety mechanism. Root cause: emergency recovery is a state machine (start -> waiting -> ready -> password change). The handler that moves a recovery from waiting to ready checks that the caller claims to approve as themselves, but never loads the recovery session named in the request to confirm it belongs to them. It passes the session id from the request body to a database update filtered only on session id and status, with no constraint tying the session to the caller. Any known waiting session can be flipped to ready by anyone, and flipping to ready resets the wait timer to now. The downstream safety check only enforces the waiting period while status is still "waiting"; once flipped to "ready" it is skipped. The password-change step then disables the victim's TOTP and removes their passkey 2FA with no further ownership check. The attacker can already decrypt the victim's recovery key (wrapped to the attacker's public key during legitimate setup); the waiting period was the only control. A companion bug addresses the "recovery approved" notification to the attacker-supplied identifier, so the victim is not alerted. Attack (seconds, no victim interaction): the attacker must have been legitimately added and accepted as the victim's emergency contact at some earlier point. (1) Start a recovery for the victim — waiting session created, 30-day timer, victim emailed. (2) Read back own recovery sessions via a normal info endpoint to get the session id. (3) Call the approve endpoint with that session id — missing ownership check flips waiting->ready, timer reset to now. (4) Complete a password change; the recovery flow wipes the victim's 2FA and replaces credentials. Impact: full account takeover of any user who ever added the attacker as an emergency contact. Exposes the victim's end-to-end encrypted photos, Ente Auth 2FA seeds (which protect the victim's other accounts — bank, email, etc.), and Ente Locker secrets; wipes the victim's own 2FA. Applies to hosted Ente (api.ente.io) and every self-hosted deployment. Affected from December 2024 through the fix. Remediation: vendor fixed it in PR #11311 (loads the recovery session and verifies it belongs to the account and contact named in the request before allowing the status change, and enforces the waiting state). Hosted users on api.ente.io are covered; self-hosted operators should update to a build including PR #11311 and can audit recovery records for sessions that moved from waiting to ready faster than the configured notice period. Vendor response was cooperative: reported 2026-05-27, confirmed and fixed by Ente 2026-07-08, CVE reserved by CERT/CC 2026-07-23, coordinated public disclosure 2026-07-26. The narrative writeup is at https://vokecyber.com/blog/cve-2026-16751-ente-emergency-recovery-bypass. --- ## Blog: The Safety Window That Closed in One Request: CVE-2026-16751 in Ente URL: https://vokecyber.com/blog/cve-2026-16751-ente-emergency-recovery-bypass Author: Louis Sanchez — Voke Cyber | Published: July 26, 2026 The story behind CVE-2026-16751 in Ente. Emergency access is hard to build safely: you want a trusted contact to rescue you, but not to seize your account at will. Ente's answer is a waiting period on emergency-contact recovery. The approval step that moves a recovery from waiting to ready never checked the session belonged to the caller, so a former emergency contact could collapse the multi-day safety window to zero in a single request, reset the victim's password, and let the recovery flow wipe the victim's 2FA — a full takeover in under a minute, including the Ente Auth 2FA seeds that guard the victim's other accounts. The lesson: the most dangerous place for a missing authorization check is inside the feature whose entire job is to be safe, because everyone reasons about break-glass flows as already-careful. Vendor response was clean — reported, confirmed, and fixed in PR #11311. CVSS 6.5. --- ## Security Research: Cal.com Cross-Tenant Webhook Plant — Authorization Bypass via Unvalidated teamId URL: https://vokecyber.com/research/calcom-cross-tenant-webhook-plant Author: Louis Sanchez — Voke Cyber | Published: July 22, 2026 An authorization bypass (CWE-639 primary, CWE-862) found by Voke Cyber in Cal.com, a widely used open-source scheduling platform. CVE-2026-16624; GitHub Security Advisory GHSA-4fwh-xxpv-xfm6; CERT/CC coordination case VRF#26-06-RPFHL. CVSS v3.1 base score 9.6 Critical, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N. Root cause: the webhook-create API (viewer.webhook.create) runs through middleware that validates ownership for two paths — an existing webhook referenced by id, and a webhook tied to one of the caller's own event types — but the create request also accepts a teamId field that is never checked against the caller's team memberships. The handler pins the owning userId to the caller but writes the attacker-supplied teamId straight into the database row, so the webhook is persisted as belonging to the victim team. Cal.com's normal delivery logic then delivers every booking event for that team to the planted subscriber URL. Attack: any authenticated account (a free account with no relationship to the victim is enough). The victim team is identified by a small incrementing numeric id, guessable or resolvable from public booking pages. A single request — POST /api/trpc/webhook/create with subscriberUrl, eventTriggers, an attacker-chosen secret, and teamId set to the victim team — returns 200 OK and plants the webhook. From then on every booking for that team is copied in full to the attacker's URL, signed with the attacker's secret. Leaked payload per booking: booker full name, email, and phone number; custom question/note answers; organizer email; and the video-call URL including its password. Because the attacker also controls the signing secret, they can forge signed webhook messages to downstream systems that trust the webhook, enabling signed phishing (e.g. a fake "meeting rescheduled" message). Broader weakness: the open-source build of Cal.com ships stub permission-check services that return "allowed" for everything (the real permission engine is closed-source and not included), quietly disabling role-based checks the code appears to perform. The webhook teamId bug is the most damaging instance; the same root cause also yields cross-team webhook read/edit, cross-tenant attendee-detail reads, a private-team member-list bypass, and members seeing webhook secrets they should not. Remediation: no vendor fix at publication; vendor unresponsive during coordination. Correct fix: validate teamId on webhook create (require the caller be an admin/owner of that team) and apply the same team-ownership check to team-webhook read/edit/delete; ship a real permission-check implementation in the open build. Interim for operators: audit the webhook table for rows whose owning user is not a member of the attached team, review subscriber URLs against expected integrations, and treat affected bookings' data and video-call credentials as compromised. Affected: Cal.com self-hosted (Community Edition) and Cal.diy SaaS; master @ commit a4a01a0 and prior releases. The narrative writeup is at https://vokecyber.com/blog/calcom-cross-tenant-webhook-plant. --- ## Blog: A Scheduling Tool Turned Into a Wiretap: The Cal.com Webhook That Trusts Its Own Input URL: https://vokecyber.com/blog/calcom-cross-tenant-webhook-plant Author: Louis Sanchez — Voke Cyber | Published: July 22, 2026 The story behind a CVSS 9.6 cross-tenant webhook plant in Cal.com. A webhook carries a booking's full attendee PII and the video-call URL and password; the create API checks ownership for the id and eventType paths but never validates the teamId, so any authenticated user can attach a webhook to any team by its numeric id and receive a live copy of every booking with one API call. The attacker also chooses the signing secret, turning it into a trusted signed channel for phishing. Root cause is an open-core pattern: the open-source build ships stub permission checks that always return allowed, so the security you can read in the source is not the security you are running. No patch available; disclosed via CERT/CC. --- ## Security Research: CVE-2026-15630 — Cross-Tenant Authorization Bypass in Casdoor IAM URL: https://vokecyber.com/research/cve-2026-15630-casdoor-cross-tenant-authz Author: Louis Sanchez — Voke Cyber | Published: July 20, 2026 CVE-2026-15630 is a cross-tenant authorization bypass (CWE-863 primary, CWE-639, CWE-269) found by Voke Cyber in Casdoor, a widely deployed open-source identity and access management platform (casdoor/casdoor) used as the single sign-on backend for multi-tenant SaaS products and as an OIDC/OAuth/SAML/LDAP provider for internal apps. CERT/CC coordination case VU#889462. CVSS v3.1 base score 9.9 Critical, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Root cause: an authorization-vs-action desynchronization. Casdoor's global authorization filter (routers/authz_filter.go) resolves the target object of a state-changing request from the URL ?id= query parameter, a design the code documents in a comment as deliberate to prevent body-spoofing of ownership. The affected controllers (controllers/user.go, controllers/permission.go, and roughly 25 more add/delete endpoints) ignore ?id= entirely and read the target from the owner and name fields of the JSON request body, and the object layer (object/*) performs no caller-authorization check. The filter authorizes one object; the controller acts on another. Attack: the attacker needs only an organization-admin account (IsAdmin = true) in any single organization; global admin is not required, and self-signup makes that threshold low. A single request carries two identities: POST /api/delete-user?id=org-attacker/attacker-admin (filter approves because ?id= names a resource the attacker owns) with body {"owner":"org-victim","name":"victim-admin"} (controller acts on the body target). The server returns 200 OK and deletes the victim in another organization. Chained: delete the victim org's users including admins; create a backdoor user with isAdmin:true in the victim org; plant a Casbin Allow rule in the built-in global-admin org to escalate to instance-wide global admin; delete the victim org's signing certificates to break SAML/OIDC federation. Reproduced end to end against a stock deployment. The same body-only pattern spans ~25 add-/delete- endpoints (user, permission, invitation, group, cert, plus about 15 more), so the flaw is systemic rather than a single handler. Remediation: no vendor fix at publication; re-verified unpatched against master, last checked at v3.115.0, on 2026-07-12. No Casdoor setting makes the filter and controllers agree. Interim mitigations: minimize organization-admin accounts, disable self-signup that auto-grants admin, require MFA on all admins; optionally add a reverse-proxy/WAF tripwire on /api/add-* and /api/delete-* that rejects requests where the body owner disagrees with the ?id= organization (exempt built-in global-admin sessions, run log-only first, cover the whole add/delete family); monitor for the ?id=-vs-body mismatch, new wildcard Casbin rules in the built-in org, cross-org admin creation or user deletion, and sudden drops in a tenant's user count. Correct code fix: derive the target from the authoritative ?id= and reject a mismatched body, plus a caller-authorization check at the object layer. Affected: all versions; no fixed release exists. Last re-verified against v3.115.0 (2026-07-12). Distinct from VU#780781 (CVE-2026-9090 through CVE-2026-9098, published 2026-05-28, covering SAML certificate/replay handling, MFA binding, and token exchange), which does not address this desync. The narrative writeup is at https://vokecyber.com/blog/cve-2026-15630-casdoor-cross-tenant-authz. --- ## Blog: When the Authorization Check and the Action Look at Different Objects: CVE-2026-15630 in Casdoor URL: https://vokecyber.com/blog/cve-2026-15630-casdoor-cross-tenant-authz Author: Louis Sanchez — Voke Cyber | Published: July 20, 2026 The story behind CVE-2026-15630 in Casdoor. Unlike most authorization bugs, the check is not missing — it runs and approves for a legitimate reason, then the controller acts on a different object than the filter authorized. The filter keys on the URL ?id=; the controllers key on the JSON body's owner/name. Every layer looks correct in isolation; the bug lives in the space between them. From a routine org-admin account this chains to deleting another tenant's users, planting a backdoor admin, and escalating to global admin of the whole instance. CVSS 9.9, no patch, disclosed via CERT/CC (VU#889462). The lesson: reviewing access control means confirming the object being checked is the same object being acted on — not just that a check exists. --- ## Security Research: CVE-2026-39878 — Unauthenticated Stored XSS to Admin Account Takeover in Chamilo LMS URL: https://vokecyber.com/research/cve-2026-39878-chamilo-lms-stored-xss Author: Louis Sanchez — Voke Cyber | Published: July 7, 2026 CVE-2026-39878 is an unauthenticated stored cross-site scripting vulnerability (CWE-79) found by Voke Cyber in Chamilo LMS, a widely deployed open-source learning management system used by universities, schools, government training programs, and companies. GHSA-gcjp-f7jm-rrrg. CVSS v3.1 base score 9.3 Critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N. Root cause: a sanitizer bypass meeting an unescaped sink. The self-registration handler (main/auth/inscription.php, line 453) sanitizes input with Security::remove_XSS(), a wrapper around HTMLPurifier. HTMLPurifier does not escape double quotes in plain text, and its event-handler detection can be defeated by inserting a null byte inside the handler keyword (on\x00load). HTMLPurifier strips the null byte but leaves the reconstructed onload handler intact in the stored value. The admin user list (main/admin/user_list.php, lines 472-475) then renders each account's first and last name inside the alt and title attributes of an avatar tag without htmlspecialchars(). The stored double quote breaks out of the attribute and the injected onload becomes a live event handler. Attack: With self-registration enabled (a common configuration for open enrollment), an unauthenticated attacker registers an account whose name field carries the null-byte-obfuscated payload. Because the image src is a valid avatar URL, onload fires automatically the moment an administrator opens the user list — a routine admin action, and the "user interaction" (UI:R) in the CVSS vector. Chamilo loads jQuery on every page, so the payload uses $.getScript() to load an external script that reads the CSRF token from the admin user-creation form (main/admin/user_add.php) and POSTs a request creating a new platform-administrator account. The attacker then logs in as admin: full platform takeover, all user data, grades, and course content. Because education data is covered by GDPR and FERPA, this is a reportable data-protection event. The fix: Chamilo 1.11.40 (fix commit 823ed10) wraps the name in htmlspecialchars(..., ENT_QUOTES, 'UTF-8') before rendering it into the attributes, and null bytes are stripped from input. Reported 2026-03-30 via GitHub private vulnerability reporting; fixed the next day; CVE assigned 2026-04-07; advisory and CVE published 2026-07-07. Vendor response was cooperative and constructive throughout. The narrative writeup is at https://vokecyber.com/blog/cve-2026-39878-chamilo-lms-stored-xss. --- ## Blog: The Null Byte That Walked Past HTMLPurifier: CVE-2026-39878 in Chamilo LMS URL: https://vokecyber.com/blog/cve-2026-39878-chamilo-lms-stored-xss Author: Louis Sanchez — Voke Cyber | Published: July 7, 2026 The story behind CVE-2026-39878 in Chamilo LMS. Chamilo sanitizes registration input with HTMLPurifier, so the interesting question was what the sanitizer assumes and whether the rest of the code holds up its end. A single null byte inside an onload handler (on\x00load) defeats HTMLPurifier's event-handler detection; the null byte is stripped and a working handler is left in the stored name. The admin user list renders that name inside an image tag's alt/title attributes with no output escaping, so the payload fires the moment an admin opens the page and creates a new platform administrator. The central lesson: input sanitization and output encoding are not the same job. A sanitizer cleans markup without knowing where the value will be rendered; only the output layer knows the value is about to sit inside a double-quoted HTML attribute and can escape for that context. Escape at the sink, every time. CVSS 9.3 Critical, unauthenticated admin takeover. Vendor response was clean: confirmed, fixed the next day, requested the CVE, credited the finding. --- ## Security Research: CVE-2026-48742 — Cross-Team IDOR in Coolify Livewire Service Components URL: https://vokecyber.com/research/cve-2026-48742-coolify-cross-team-idor Author: Louis Sanchez — Voke Cyber | Published: June 24, 2026 CVE-2026-48742 is a cross-team IDOR vulnerability (CWE-639 primary, CWE-862) found by Voke Cyber in Coolify, an open-source self-hostable PaaS alternative to Heroku/Netlify/Vercel with 40,000+ GitHub stars, built on Laravel 12 and Livewire 3. Root cause: Coolify's entire Laravel policy layer had been temporarily disabled — every policy file in app/Policies/ contained commented-out authorization logic with the annotation "Authorization temporarily disabled." This left per-query team-ownership scopes as the sole access control mechanism. The Livewire service management component (app/Livewire/Project/Service/Index.php) loaded service objects using a bare UUID lookup with no team-ownership scope, bypassing the only remaining access control layer. Architecture context: Coolify is multi-tenant. A single instance hosts multiple teams; each team owns projects, environments, and resources running on team-owned servers via SSH. Cross-team isolation depended entirely on per-query scopes after the policy layer was disabled. The sibling component (Configuration.php, one level up in the same URL hierarchy) applied the correct team-scoped chain — Index.php simply did not. Attack: Any authenticated user on the instance who knows a victim's service UUID navigates to /project/[own_uuid]/environment/[own_uuid]/service/[victim_uuid]/[victim_stack_uuid]. The project and environment UUIDs are never validated against the loaded service. From this page the attacker can: read victim service config including environment variables; rewrite the docker-compose by swapping the container image (submitApplication); trigger a pull-and-restart (Heading::pullAndRestartEvent) causing Coolify to SSH into the victim's server and execute the attacker-supplied container; delete the victim's service using the attacker's own password for the confirmation step; or stop the victim's running production service. Test gap: Coolify had dedicated cross-team IDOR test files but none covered Project/Service/Index, Heading, or DatabaseBackups. CVSS v3.1 base score 9.9 Critical, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Scope is changed (S:C) because impact crosses team boundaries and reaches the victim's physical server infrastructure. The fix: PR #10358, merged 2026-05-22, shipped in v4.1.1. Vendor response was exemplary: andrasbacsai accepted promptly, fixed in four days, requested CVE, credited the researcher. The narrative writeup is at https://vokecyber.com/blog/cve-2026-48742-coolify-cross-team-idor. --- ## Blog: Authorization Temporarily Disabled: The Comment That Opened Coolify to Cross-Team IDOR URL: https://vokecyber.com/blog/cve-2026-48742-coolify-cross-team-idor Author: Louis Sanchez — Voke Cyber | Published: June 24, 2026 The story behind CVE-2026-48742 in Coolify. A CVSS 9.9 cross-team IDOR lets any authenticated user navigate to another team's production services. Worst-case path: swap the container image, trigger pull-and-restart, Coolify SSHes the victim's server to run the attacker's container. The central angle: every Laravel policy was commented out with "Authorization temporarily disabled." Temporary security bypasses become the actual security model when never cleaned up. The correct team-scoped chain existed in the sibling component (Configuration.php) — the fix applied what was already there. Vendor response was positive throughout. --- ## Security Research: CVE-2026-35198 — Stored XSS in HeyForm Rich-Text Fields URL: https://vokecyber.com/research/cve-2026-35198-heyform-stored-xss Author: Louis Sanchez — Voke Cyber | Published: June 22, 2026 CVE-2026-35198 is a stored cross-site scripting vulnerability (CWE-79 primary, CWE-116) found by Voke Cyber in HeyForm, an open-source form builder available as self-hosted software and a cloud service at heyform.net. Root cause: HeyForm's form builder supports rich-text fields (formatted text blocks, welcome screens, description elements) that store HTML in the form schema JSON. At render time, the stored HTML is written to the DOM via element.innerHTML or React's dangerouslySetInnerHTML with no sanitization — no DOMPurify or equivalent library applied. Any team member with form-edit access can inject arbitrary HTML, including JavaScript, into a rich-text block. Attack surfaces: (1) Form builder — anyone opening the form in the editor triggers the payload, including the team owner during routine review. (2) Live public form — any anonymous respondent filling out a published form triggers the payload; no HeyForm account required. (3) Response dashboard — team members viewing responses may trigger the payload. Attack chain: team member injects payload into a rich-text block (invisible in rendered form). Team owner opens form in builder (routine admin action). Payload fires in owner's browser. Session credentials exfiltrated to attacker. Attacker takes over team ownership, exports all respondent PII, adds attacker-controlled accounts, modifies or deletes forms, accesses billing settings. Impact: CVSS v3.1 base score 8.7 (High), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N. The GitHub CNA and NVD publish 9.0 (Critical) for the same issue, using A:H instead of A:N. Scope is changed because impact extends beyond the attacker's form-edit privilege to the team owner's account and all respondent data. The fix: commit cc97d27 ("Fix stored XSS in form schema rich text") applies sanitization before DOM insertion. No tagged release version explicitly documents this fix. Cloud (heyform.net) received it automatically. Self-hosted operators must verify presence of cc97d27 manually via git log. Silent disclosure problem: the maintainer (iMuFeng) fixed the bug and closed the GitHub Security Advisory thread. In GitHub's workflow, "Close" dismisses the report without creating a public advisory, Dependabot alert, or NVD entry. Follow-up comments on 2026-05-14 and 2026-05-23 requesting the publish step received no response. Email to GitHub Security Lab on 2026-06-10 confirmed they can push the CVE record once a public write-up URL is provided. This advisory is that write-up. Remediation: run git log --oneline | grep cc97d27 to verify the fix is present; update if not; do not host public forms on an unpatched instance; review team membership. The narrative writeup is at https://vokecyber.com/blog/cve-2026-35198-heyform-stored-xss. --- ## Blog: CVE-2026-35198: HeyForm's Stored XSS Was Fixed. Then the Advisory Was Closed Without Being Published. URL: https://vokecyber.com/blog/cve-2026-35198-heyform-stored-xss Author: Louis Sanchez — Voke Cyber | Published: June 22, 2026 The story behind CVE-2026-35198 in HeyForm. A CVSS 8.7 High stored XSS in rich-text form fields (the GitHub CNA and NVD publish 9.0) allows any team member to implant a persistent payload that silently fires in the team owner's browser, enabling full team ownership takeover. The payload also fires for anonymous respondents on public forms. The disclosure angle: the maintainer fixed the bug (commit cc97d27) but selected "Close" instead of "Publish" in GitHub's advisory UI, which dismissed the report without creating any public signal. Two follow-up comments requesting the publish step went unanswered. An email to GitHub Security Lab confirmed they can push the CVE record once a public write-up URL is provided — this article is that write-up. The lesson: a fix that is invisible to operators is not a complete fix. Self-hosted HeyForm operators running a pinned version had no Dependabot alert, no NVD entry, and no advisory for four months to tell them a critical vulnerability was fixed. The distinction between "Close" and "Publish" in GitHub's advisory workflow has real consequences for the ecosystem. --- ## Security Research: CVE-2026-48507 — Snipe-IT Admin Lockout via Bulk User Editing URL: https://vokecyber.com/research/cve-2026-48507-snipe-it-admin-lockout Author: Louis Sanchez — Voke Cyber | Published: June 8, 2026 CVE-2026-48507 is an incorrect-authorization flaw (CWE-863) found by Voke Cyber in Snipe-IT, a widely used open-source IT asset management platform. Through bulk user editing, a user holding only the granular users.edit permission could modify protected account flags that should be reserved for administrators, including the activated flag (which controls whether an account can log in) and the ldap_import flag (which affects password resets). By disabling the activated flag on the administrator accounts in a single bulk edit, a low-privilege user could lock every administrator out of the instance. Mechanism: the bulk user edit path did not enforce field-level authorization based on the caller's privileges. The normal one-at-a-time edit screen restricted which fields a low-privilege user could change; the bulk path did not. The application checked "can edit users" but never "is this user allowed to change this specific, security-relevant field." Impact: CVSS v3.1 base score 7.1 (High), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H. No confidentiality impact; low integrity impact; high availability impact (a full admin lockout, which is a denial of service against the people who run the system). Exploitation requires an authenticated account with the users.edit permission (PR:L), making it primarily an insider-threat and compromised-account risk. Affected versions: all Snipe-IT versions before 8.6.0. Fixed in: 8.6.0. There is no documented workaround; remediation is to upgrade to 8.6.0 and, in the interim, limit who holds the users.edit permission. Disclosure: CVE reserved May 21, 2026; GitHub Security Advisory GHSA-6f75-x745-xcpr published May 27, 2026; CVE record published on cve.org June 8, 2026. Coordinated disclosure throughout; the Snipe-IT maintainers credited the reporter. The narrative writeup is at https://vokecyber.com/blog/cve-2026-48507-snipe-it-admin-lockout. --- ## Blog: How We Found CVE-2026-48507 in Snipe-IT URL: https://vokecyber.com/blog/cve-2026-48507-snipe-it-admin-lockout Author: Louis Sanchez — Voke Cyber | Published: June 8, 2026 The narrative behind CVE-2026-48507 (full technical advisory at https://vokecyber.com/research/cve-2026-48507-snipe-it-admin-lockout). This Snipe-IT incorrect-authorization flaw came out of Voke Cyber's ongoing program of manual source-code review and coordinated disclosure of open-source software. The lesson for buyers: granular permissions create a quiet assumption that every code path enforces them the same way, and bulk operations are where that assumption breaks. A scanner cannot reason that "can edit users" should not also mean "can disable every administrator." That kind of broken access control only surfaces when a human tests the authorization model by hand with a low-privilege account. It is one of the most common and most damaging categories of finding on real engagements, and almost none of it is caught by a tool. --- ## Security Research: CVE-2026-42318 — GLPI Arbitrary Item Deletion via Planning URL: https://vokecyber.com/research/cve-2026-42318-glpi-arbitrary-deletion Author: Louis Sanchez — Voke Cyber | Published: June 4, 2026 CVE-2026-42318 is an authorization bypass (CWE-862, Missing Authorization) found by Voke Cyber in GLPI, a widely deployed open-source IT asset management and service-desk platform. A user with access to the Planning feature — a technician-level privilege, not an administrator — can delete any object in the entire GLPI instance, bypassing the permissions that should protect those objects. Mechanism: the delete action reachable through the planning module acts on a user-supplied item reference but does not verify that the requester is authorized to delete that specific target object. It is an insecure direct object reference (IDOR) — the endpoint checks that you can use planning, not that the object you are deleting is yours to delete. Impact: CVSS v4.0 base score 7.0 (High), vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N. No confidentiality impact (not data theft), but high integrity and availability impact — arbitrary objects such as tickets and assets can be destroyed. Exploitation requires an authenticated technician account with planning access (PR:H), making it primarily an insider-threat / assume-breach risk. Affected versions: GLPI 9.5.0 through 10.0.24, and 11.0.0 through 11.0.6. Fixed in: 10.0.25 and 11.0.7. Workaround: disable delete rights for users' planning access until patched. Disclosure timeline: reported to GLPI via GitHub private vulnerability reporting on April 24, 2026; GitHub Security Advisory GHSA-w7mr-3vwm-2j22 published June 1, 2026; CVE record published on cve.org June 3, 2026. Coordinated disclosure throughout; the GLPI maintainers credited the reporter. The narrative writeup is at https://vokecyber.com/blog/cve-2026-42318-glpi-arbitrary-deletion. --- ## Blog: How We Found CVE-2026-42318 in GLPI URL: https://vokecyber.com/blog/cve-2026-42318-glpi-arbitrary-deletion Author: Louis Sanchez — Voke Cyber | Published: June 4, 2026 The narrative behind CVE-2026-42318 (full technical advisory at https://vokecyber.com/research/cve-2026-42318-glpi-arbitrary-deletion). Voke Cyber runs an ongoing program of manual source-code review of widely used open-source software and reports what it finds through coordinated disclosure. This GLPI authorization bypass came out of that program. The lesson for buyers: a vulnerability scanner would have passed this application. Scanners match known signatures and outdated versions; they cannot reason that "access to the planning calendar" should not also mean "permission to delete the asset inventory." That is business logic, and logic is invisible to pattern matching. Broken access control is one of the most common and most damaging findings on real engagements, and it almost always takes a human reading the code or testing the authorization model by hand. That is the difference between an automated scan and a manual penetration test. --- ## Security Research: Vulnerability Disclosure Policy URL: https://vokecyber.com/research/disclosure-policy Voke Cyber's coordinated vulnerability disclosure policy. How we disclose findings in third-party software: we report privately to the vendor or maintainer first, work with them to validate the fix, and give reasonable time before publishing — a 90-day standard window, extended when a vendor is engaged in good faith, or shortened if a fix ships sooner or the issue is already being exploited. We request a CVE where appropriate, credit the vendor for the fix, and publish an advisory only after a fix is available, holding back exploit code and fine-grained detail while users are still patching. We do not sell, trade, or weaponize vulnerabilities, and we never ask a vendor for payment to stay quiet. Reporting a vulnerability to us: email info@vokecyber.com with "Security Disclosure" in the subject, include enough detail to reproduce, and give us reasonable time to fix before disclosing publicly. We ask researchers to act in good faith, not to access or destroy data that is not theirs, and not to degrade the service. In return, for good-faith research that follows the policy, we will not pursue legal action, we will acknowledge and update you, and we will credit you if you want it. Scope: vokecyber.com and the systems Voke Cyber operates; the policy does not authorize testing of clients or any third party. Principles: fix first, publish second; credit where it is due; no exploitation, no extortion, no selling findings; clear, verifiable advisories tied to the public record. --- ## Blog: PCI DSS 4.0 Penetration Testing Requirements: What Changed URL: https://vokecyber.com/blog/pci-dss-4-penetration-testing-requirements Author: Louis Sanchez | Published: May 23, 2026 | 11 min read PCI DSS 4.0 became mandatory on March 31, 2025, and it reshaped what Requirement 11.4 expects from penetration testing. The standard now requires both external and internal penetration tests at least annually and after any significant change, application-layer and network-layer testing, and explicit testing of the segmentation controls that isolate the cardholder data environment (CDE) from out-of-scope networks. ### What Changed Under Requirement 11.4 - A documented penetration testing methodology covering the entire CDE perimeter and critical systems - External and internal penetration testing at least once every 12 months and after significant infrastructure or application changes - Segmentation testing at least every 12 months (every 6 months for service providers) to confirm isolation controls are effective - Remediation of exploitable vulnerabilities found during testing, followed by retesting to verify the fix - Retention of penetration test results and remediation evidence for assessor review ### Segmentation Testing If you use network segmentation to reduce PCI scope, Requirement 11.4.5 requires testing that the segmentation actually works — proving that systems outside the CDE cannot reach in. Failed segmentation is one of the most common ways an environment that looks audit-ready turns out to be non-compliant in practice. ### What Organizations Need to Do Now Map your CDE, confirm your penetration testing scope matches it, schedule annual external and internal tests plus segmentation validation, and build in time for remediation and retesting before your assessment. The penetration test report must include enough detail — methodology, findings, severity, and remediation status — for a QSA to rely on it. --- ## Blog: EU AI Act Article 15 — What Adversarial Testing Actually Means URL: https://vokecyber.com/blog/eu-ai-act-article-15-adversarial-testing Author: Louis Sanchez | Published: May 7, 2026 | 10 min read Plain-English breakdown of Article 15 of the EU AI Act (Regulation 2024/1689). The August 2, 2026 deadline for high-risk AI systems has now passed; new Annex III high-risk systems are already in scope, and legacy systems already on the market have until August 2, 2027 unless substantially modified. The Voke Cyber cybersecurity testing engagement runs three to four weeks from kickoff (signed Article 9(8) Metric Pre-Registration Document) to delivery of the Annex IV-aligned cybersecurity documentation support package. Anyone offering Article 15 cybersecurity testing in less than three weeks has no time to get a Metric Pre-Registration Document signed. ### What Article 15 Actually Requires Article 15(1) sets the high-level mandate: high-risk AI systems must be "designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity." Article 15(5) is the operative cybersecurity clause: systems "shall be resilient as regards attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities." Recital 77 specifies the five cybersecurity threat categories the technical solution must address: - Data poisoning (manipulating the training dataset) - Model poisoning (manipulating pre-trained components used in training) - Adversarial examples / model evasion - Confidentiality attacks (membership inference, training-data extraction for LLMs) - Model flaws Article 15(4) adds robustness against errors and faults. Article 12 mandates automatic logging. Article 9(8) requires testing against pre-defined metrics before market placement. ### What Voke Cyber Delivers The engagement is structured around three artifacts the customer sees and signs: 1. **Kickoff** — Architecture review and signed/countersigned Article 9(8) Metric Pre-Registration Document. The pass/fail thresholds for each Article 15(5) category are locked before any testing begins. Structurally non-backdateable. 2. **Active testing** — Six article-mapped phases producing Signed Test Log entries: Phase 2 Data Poisoning Assessment, Phase 3 Model Poisoning / Supply Chain Integrity, Phase 4 Adversarial Examples + OOD, Phase 5 Confidentiality / Membership Inference, Phase 6 Model Flaws & Robustness, Phase 7 Article 12 Logging Verification. Phases 2 and 3 are conditional with documented zero-hour scope-out for systems without an owned training pipeline or imported pre-trained components. 3. **Final artifacts** — Annex IV-aligned cybersecurity documentation support package: security assessment summary, testing records and assessment log, findings register with risk ratings, description of identified cybersecurity weaknesses and observed failure modes, remediation recommendations and prioritization guidance, supporting cybersecurity assessment evidence. Plus the final assessment report and a 30-minute debrief call. Verification of remediated findings is available as a separately quoted Change Order, not part of the base engagement. ### Who Article 15 Applies To Annex III lists eight high-risk categories: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration/asylum/border, and administration of justice. Plus AI used as safety components of products under Annex I harmonisation legislation. Article 2 extends extraterritorially: providers and deployers established outside the EU are in scope when their AI's output is used inside the EU. US-based fintech, healthcare, and SaaS companies serving EU customers are commonly in scope. ### Compliance Timeline - February 2, 2025 — Prohibited AI practices banned (already in force) - August 2, 2025 — GPAI governance and AI literacy obligations (already in force) - August 2, 2026 — High-risk AI systems (Annex III) must meet their obligations - August 2, 2027 — High-risk AI on the market without substantial modification ### Penalties (Article 99) - Up to €35 million or 7% of total worldwide annual turnover (whichever is higher) for prohibited AI practices - Up to €15 million or 3% for non-compliance with operator/provider obligations (Article 15 violations land here) - Up to €7.5 million or 1% for incorrect information to authorities ### What's Out of Scope Under This Engagement - Article 5 prohibited practices screening (legal interpretation) - Article 9(1)–(7) full risk management system - Article 10 data governance and bias / fairness testing - Article 27 Fundamental Rights Impact Assessment (FRIA) - Article 43 conformity assessment procedure - Article 47/48 EU Declaration of Conformity / CE marking - Article 72 post-market monitoring plan - Prompt injection (covered under Voke's separate LLM/AI Penetration Testing service line, or scoped as a Change Order) - Model inversion (separate engagement) - Market placement determination (customer's qualified legal counsel) - Legal advice or legal opinion of any kind Voke Cyber produces signed cybersecurity testing evidence aligned to the testable cybersecurity requirements of the EU AI Act. Compliance, conformity assessment, and market placement determinations remain the customer's responsibility with qualified legal counsel. --- ## Blog: SOC 2 and Penetration Testing: What You Need to Know Before Your Audit URL: https://vokecyber.com/blog/soc2-penetration-testing-requirements SOC 2 does not explicitly mandate penetration testing, but auditors almost universally expect it. The Security Trust Service Criteria includes control point CC7.1, which requires organizations to detect and monitor for new vulnerabilities. Demonstrating that you actively test your defenses is the most straightforward way to satisfy auditors. ### What Auditors Look For - External network penetration test covering internet-facing infrastructure - Web application penetration test covering applications handling customer data - Gray-box or white-box testing preferred for thorough coverage - Manual testing, not just automated scanning - Report with executive summary, detailed findings, severity ratings, proof-of-concept evidence, and remediation guidance - Evidence of remediation (retesting) ### Timing For SOC 2 Type II, conduct the penetration test 3 to 4 months before the observation period ends. Allow 2 to 4 weeks for remediation and 30 days for retesting. For SOC 2 Type I, complete the pentest including remediation before the audit date. Plan for annual penetration testing going forward. ### Common Mistakes 1. Waiting until the last minute to schedule 2. Using a vulnerability scan instead of a penetration test 3. Not remediating findings before the audit 4. Pentest scope that doesn't match SOC 2 scope 5. Using a provider without recognized security certifications ### Budget Market-wide, a typical SaaS application with supporting infrastructure runs $8,000 to $20,000 depending on complexity. Voke Cyber's own prices start below that range: web application testing starts at $3,500, and every service has a published starting price. The firm performing the audit cannot also perform the penetration test. --- ## Blog: Why Charlotte, NC Businesses Are Prime Targets for Cyberattacks URL: https://vokecyber.com/blog/charlotte-businesses-cyberattack-targets Charlotte is the second-largest banking center in the United States. The concentration of financial services, healthcare providers, and growing tech companies makes the region a high-value target for cybercriminals. North Carolina saw a 44% surge in ransomware attacks, and the NC Attorney General's 2024 Data Breach Report showed a record number of breaches affecting the state. Key risk factors include the density of financial data, rapid startup growth outpacing security investment, healthcare organizations handling protected health information, and supply chain exposure from interconnected regional businesses. --- ## Blog: How Much Does a Penetration Test Cost in 2026? URL: https://vokecyber.com/blog/how-much-does-penetration-test-cost Voke Cyber's published starting prices for 2026: vulnerability assessment $1,500; phishing simulation $2,000; web application $3,500; developer API security $3,500; cloud security $3,000; PCI scanning $3,000; external penetration testing $3,500; LLM/AI penetration testing $4,500; internal penetration testing $5,000; mobile application $5,500; thick client applications $7,000; red teaming $8,000; IoT and embedded systems $10,000; EU AI Act cybersecurity assessment $10,000. These are the same numbers listed on each service page. Market-wide ranges for comparison (what the wider market charges, not Voke Cyber pricing): web application pentests $3,000 to $15,000. External network tests $3,500 to $12,000. Internal network tests $5,000 to $20,000. API pentests $3,000 to $12,000. Mobile app tests $5,000 to $20,000. Cloud environment assessments $3,000 to $30,000. Red team engagements $20,000+. Factors that affect cost include application complexity, number of targets, testing methodology (black-box vs. white-box), compliance requirements, and timeline urgency. The average cost of a data breach was $4.44 million (IBM, 2025 Cost of a Data Breach Report), making penetration testing a high-ROI investment. --- ## Resource: Pentest Remediation Playbook URL: https://vokecyber.com/resources/remediation-playbook/ Step-by-step fixes for the 30 most common internal penetration testing findings across Active Directory, network protocols, credentials, host security, and SSL/TLS. Each finding includes the issue, why it matters, and copy-paste remediation commands. --- ## Resource: WebSocket Penetration Testing Guide URL: https://vokecyber.com/resources/websocket-security-testing-guide/ A complete methodology for testing WebSocket security, including CSWSH (Cross-Site WebSocket Hijacking), running SQLMap over WebSockets, testing Socket.IO and SignalR implementations, authorization bypass patterns, and remediation with working code examples. Targeted at developers and pentesters working with real-time applications. ### What's Covered - WebSocket protocol fundamentals (RFC 6455) and how they differ from HTTP - Cross-Site WebSocket Hijacking (CSWSH) — origin validation bypasses and session riding - Authentication and authorization testing across upgrade, connect, and message phases - Running SQLMap and other classic web tools over WebSocket message bodies - Testing Socket.IO, SignalR, and other higher-level frameworks - Tooling: Burp Suite WebSocket support, custom Python scripts, ZAP, OWASP WebSocket testing tips - Remediation patterns: CSRF tokens for the upgrade handshake, origin validation, message-level authorization, rate limiting, payload size limits ### Who This Is For - Penetration testers expanding from HTTP to WebSocket testing - Backend engineers building real-time applications who want to understand attack surface before shipping - Security engineers reviewing third-party WebSocket libraries --- ## Resource: Compliance-to-Pentest Matrix URL: https://vokecyber.com/resources/compliance-pentest-matrix A reference mapping 10 major compliance frameworks to their actual penetration testing requirements, citation, frequency, and scope, fact-checked against current documentation as of September 2026 (not whatever was true when the framework was first written about). Includes an 8-page companion PDF (Voke_Cyber_Compliance_Pentest_Matrix.pdf) with the same content. ### Frameworks Covered - **Required** (explicitly mandates security testing): PCI DSS v4.0.1 (Req. 11.4.2/11.4.3), FedRAMP (annual 3PAO pentest), NY DFS 23 NYCRR 500 (Section 500.5), EU AI Act (Article 15(5), resilience against exploitation attempts) - **Expected** (not explicitly mandated, but auditors will ask for it): SOC 2 (penetration testing is actually named in CC4.1, not the more commonly cited CC7.1, which covers vulnerability scanning), ISO/IEC 27001:2022 (Annex A.8.8, A.5.36, A.8.34), CMMC Level 2+ (maps to NIST SP 800-171 Rev. 2) - **Recommended** (framework recommends security testing; pentest is the accepted method): HIPAA (45 CFR 164.308(a)(1)(ii)(A)/(B)), NIST CSF 2.0 (ID.RA, PR.PS, DE.CM), GDPR (Article 32(1)(d)) ### Notable 2025-2026 Changes Reflected - CMMC: DoD suspended the "Phase 2" third-party (C3PAO) assessment requirement in 2026 (binding class deviation September 3, 2026); most Level 2 work now runs on self-assessment rather than third-party review. - FedRAMP: mid-transition to "FedRAMP 20x" under the 2026 Consolidated Rules, replacing the Rev 5 control catalog with continuously-validated Key Security Indicators for Low/Moderate baselines, mandatory for new authorizations by January 1, 2027. - NY DFS: the fixed "bi-annual vulnerability assessment" requirement was replaced by risk-based automated scanning in the 2023 Second Amendment, effective May 2025. - ISO 27001: most published content still cites 2013-era Annex A control numbers (e.g. A.12.6.1, A.18.2.3), which were fully superseded by the 2022 revision's 93 controls across 4 themes; no certification body audits against the old numbering anymore. --- ## Resource: DNS Security Checklist (NIST SP 800-81r3) URL: https://vokecyber.com/resources/dns-security-checklist/ A free DNS security posture checklist aligned to NIST Special Publication 800-81r3. The guide walks through six areas to check, fix, and document, designed for small-to-mid-sized teams that don't have a dedicated DNS engineer but need to demonstrate DNS hygiene to auditors, customers, or insurers. ### The Six Checklist Areas 1. **DNSSEC and resolver security** — chain-of-trust validation, DNSKEY rotation, NSEC3 vs. NSEC3-RSA usage, and resolver hardening on Windows DNS, BIND, and PowerDNS. 2. **Authoritative server configuration** — split horizon, transfer restrictions, version banner suppression, and zone integrity checks. 3. **Email-related DNS records** — SPF, DKIM, and DMARC alignment to prevent spoofing of your domain in phishing campaigns. 4. **CAA records** — Certificate Authority Authorization to limit which CAs can issue certs for your domain. 5. **Subdomain takeover prevention** — auditing dangling CNAMEs pointing to deprovisioned cloud resources (Azure, AWS S3, Heroku, etc.). 6. **Monitoring and logging** — query log retention, anomaly alerting, and DNS exfiltration detection signals. ### Why Auditors Care About DNS DNS is one of the most under-monitored attack surfaces. SOC 2, ISO 27001, and PCI DSS all touch DNS controls indirectly through network segmentation, change management, and incident detection requirements. The checklist gives your team a single document to attach as evidence of DNS due diligence. --- ## Resource: Stakeholder Guide to Pentest Reports URL: https://vokecyber.com/resources/stakeholder-guide/ A guide for executives, board members, compliance officers, and engineering leaders who need to interpret a penetration test report without becoming security specialists. Walks through the eight questions every stakeholder should be able to answer after reading a pentest report. ### The Eight Stakeholder Questions 1. What was actually tested — and what wasn't? 2. How realistic was the test — black-box, gray-box, or white-box? 3. What's the worst thing the tester could do? 4. Which findings represent real business risk vs. theoretical exposure? 5. What needs to be fixed before we can claim remediation? 6. Were any findings already known and accepted? 7. Will retesting validate the fixes? 8. What changed since the last test? ### How to Read the Severity Ratings Most reports use CVSS v3.1 (Critical / High / Medium / Low / Informational). The guide explains why CVSS alone isn't enough — a "Medium" SQL injection in your billing system is more urgent than a "High" finding in an isolated lab environment. Stakeholders should always read severity *with* exploitability and business context. ### What to Push Back On - Findings without proof-of-concept evidence - Severity ratings that don't account for compensating controls - "Best practice" recommendations dressed up as findings - Missing executive summaries - No clear remediation path for each finding --- ## About: Louis Sanchez URL: https://vokecyber.com/about/louis-sanchez Louis Sanchez is the founder and Principal Security Consultant of Voke Cyber. He brings 18 years in Information Security and 7+ years in Offensive Security, with 1,000+ penetration tests completed across web applications, APIs, mobile applications, cloud environments (AWS, Azure, GCP), networks (external and internal), IoT/embedded systems, thick clients, and Active Directory. ### Certifications - **OSCP** — Offensive Security Certified Professional - **OSWA** — Offensive Security Web Assessor - **CISSP** — Certified Information Systems Security Professional - **CCSK** — Certificate of Cloud Security Knowledge - One of the first professionals certified in Metasploit Pro ### Why Founders and CISOs Work With Louis Directly - Every engagement is scoped, tested, and reported by Louis or a hand-picked senior tester (5+ years minimum, no junior analysts) - No account managers between the client and the person doing the testing - Reports are written for both executives (business impact) and developers (step-by-step remediation) - Free retesting included with every engagement, with a 30-day window for remediation --- ## Location: Penetration Testing in Charlotte, NC URL: https://vokecyber.com/charlotte Voke Cyber serves the Greater Charlotte metro and surrounding markets including Rock Hill, Fort Mill, Gastonia, Concord, and Huntersville. Charlotte is the second-largest banking center in the United States, and the region's density of financial services, healthcare providers, manufacturers, and growing tech companies makes local cybersecurity expertise particularly valuable. ### Why Choose a Charlotte-Based Pentesting Firm - **Local presence** — available for on-site assessments, in-person kickoffs, and face-to-face report walkthroughs - **Time zone overlap** — full Eastern Time business-hours coverage, no offshore handoffs - **Regional context** — familiarity with NC and SC compliance landscapes including state breach notification laws and industry-specific regulators - **Same-day in-person availability** for urgent incidents within the metro ### Industries Served Locally - Charlotte fintech, banking, and payment-processing companies - Regional healthcare systems and health-tech vendors - Manufacturers across the Catawba and Piedmont corridors - SaaS startups in the Innovation Quarter and University Research Park - Education technology and K-12 / higher education institutions Complete methodology for testing WebSocket security. Covers Cross-Site WebSocket Hijacking (CSWSH), SQLMap over WebSockets, Socket.IO and SignalR testing, authorization bypass, and remediation with working code examples.