Penetration Test Brief — Brekz PrestaShop Hosting Infrastructure¶

Document version: 1.0
Date: June 2026
Status: Draft — placeholders marked [TBD] must be completed before handover to the security specialist
Owner: Flooris B.V. on behalf of Brekz Group

1. Introduction¶

Brekz Group operates a multi-country European pet supplies e-commerce platform serving customers in the Netherlands, Belgium, Germany, France, Austria, Italy, Denmark, Switzerland, and Sweden. The primary revenue-generating system is * brekz-prestashop*, a PrestaShop 1.6 e-commerce engine running on dedicated Hetzner hardware. This system is the authoritative source for all products, customers, orders, and inventory across all countries.

Brekz Group commissions this penetration test to obtain an independent, expert assessment of the security posture of the web hosting infrastructure and the PrestaShop application. The findings will be used to prioritise and remediate security risks and to support ongoing compliance efforts (see also the ISO 27001 / ISAE 3402 gap analysis).

End-of-life software

The PrestaShop installation runs on PHP 7.2 (end-of-life since November 2019) and PrestaShop 1.6 (end-of-life since October 2022). Both receive no upstream security patches. The security specialist should treat these as high-risk factors and actively probe for known CVEs in both the runtime and the application.

Shared production server

The production server hosts three environments simultaneously: Production, Test, and Acceptance. Any active exploitation or load-intensive testing carries a risk of cross-environment impact and production disruption. See the Rules of Engagement section.

2. Authorization¶

This penetration test is formally authorised by Brekz Group. The security specialist and their employer are granted explicit permission to perform the security testing activities described in this document against the systems listed in the scope section.

Field	Value
Authorising entity	Brekz Group B.V.
Authorising contact	`[TBD — name, title, signature]`
Date of authorisation	`[TBD]`
Valid testing window	`[TBD — start date]` to `[TBD — end date]`

Get-out-of-jail letter

A signed authorization letter will be provided separately. The security specialist must carry (a digital copy of) this letter and present it upon request. If automated security systems (e.g., Cloudflare, Hetzner abuse detection) flag testing activity, Brekz will act as point of contact to unblock the tester. See Points of Contact.

3. Scope¶

3.1 Domains (via Cloudflare)¶

All testing is performed through Cloudflare — i.e., via the public domain names listed below, as a real-world attacker would. Cloudflare WAF bypass attempts are explicitly in scope.

Domain	Country	Environment
www.brekz.nl	Netherlands	Production
www.brekz.be	Belgium	Production
www.brekz.de	Germany	Production
www.brekz.fr	France	Production
www.brekz.at	Austria	Production
www.brekz.it	Italy	Production
www.brekz.dk	Denmark	Production
www.brekz.ch	Switzerland	Production
www.brekz.se	Sweden	Production
www.brekz.com	International	Production
`[TBD — test subdomain]`	—	Test
`[TBD — acceptance subdomain]`	—	Acceptance

3.2 Application entry points¶

The following application entry points are explicitly in scope:

Public storefront — product listings, search, product detail pages, category pages
Customer account area — registration, login, order history, address management, newsletter opt-in
Checkout flow — cart, address, payment selection, order confirmation
PrestaShop admin panel — accessible at /administrator on all domains; publicly reachable from the internet
Cron job HTTP endpoints — any cron scripts that are triggered via HTTP/wget (see technical context)
API endpoints and module URLs — including /module/* paths (e.g., brekz_my_account_api, copernica, payment callbacks)

3.3 Server infrastructure¶

Item	Value
Hosting provider	Hetzner (dedicated server)
Origin IP range	`[TBD — provide before test starts]`
Operating system	`[TBD]`
Open ports (known)	80 (HTTP), 443 (HTTPS), `[TBD — SSH port, database port if exposed]`

Port scanning and service enumeration against the origin IP(s) is in scope.

3.4 Cloudflare attack surface¶

As the primary CDN and security layer, the following Cloudflare-specific attack vectors are in scope:

WAF rule bypass techniques (encoding, fragmentation, HTTP smuggling)
Cache poisoning attacks via Cloudflare edge cache (3-hour TTL configured)
Host header injection to bypass Cloudflare and reach origin
Exploiting cache rule exclusions (e.g., paths excluded from caching such as /administrator, /warenkorb, search URLs)

4. Out of Scope¶

The following systems and techniques are explicitly excluded from this engagement:

Out of scope	Reason
Cloudflare infrastructure itself (Cloudflare's own systems, dashboards)	Third-party SaaS — not owned by Brekz
Docdata / CS Payments payment gateway	Third-party payment processor
DPD SOAP web service	Third-party logistics API
Copernica email marketing platform	Third-party SaaS
Algolia search infrastructure	Third-party SaaS
Exact Online / Exact Globe	Third-party ERP
Trustpilot	Third-party SaaS
Other Brekz services (brekz-website, brekz-shop-backend, brekz-cms, brekz-logistics, brekz-copernica, brekz-exact)	Separate services, separate infrastructure; not in scope for this engagement
Social engineering and phishing	Explicitly excluded
Physical security testing	Not applicable for this engagement
Brekz employee endpoints and devices	Out of scope
DNS infrastructure (Cloudflare-managed DNS)	Third-party

DoS / load testing — open item

Denial-of-service and load-intensive attacks against production were not explicitly addressed in the initial scoping. This must be agreed in writing before the engagement starts. The recommendation is to permit load testing only against the Test or Acceptance environment and to explicitly prohibit any action that causes production downtime.

5. Technical Context¶

The security specialist should familiarise themselves with the following architectural details before starting the engagement.

5.1 Core application¶

Attribute	Detail
Application	PrestaShop 1.6
Language / runtime	PHP 7.2 (EOL)
Database	MySQL / MariaDB
Queue system	Beanstalkd
Web server	`[TBD — Apache / Nginx / LiteSpeed]`

5.2 Cron job activity¶

The server runs a large number of scheduled cron jobs, some firing as frequently as every 2 minutes. This has two security implications:

Noise — Automated cron traffic may mask or interfere with scan results.
Attack surface — Several cron scripts appear to be triggered via HTTP/wget (cron_wget.sh), which may expose HTTP-triggerable endpoints.

Cron scripts worth investigating include:

Script	Schedule	Risk
`cron_wget.sh`	Daily	HTTP endpoint trigger — potential SSRF or unauthorized trigger
`set_environment_*.sh`	Every 2–30 min	Environment mutation scripts — check for injection
`process_changes_from_hds.sh`	Hourly	External data processing — check for deserialization / injection
`cron_docdata_updates*.sh`	Every 2 min	Payment processor callback processing

5.3 External integrations (attack surface)¶

These integrations receive or process data from external parties and may introduce injection vectors:

Integration	Protocol	Direction	Risk area
DPD Shipper	SOAP (XML)	Inbound responses	XXE, XML injection
Docdata / CS Payments	HTTP callbacks	Inbound	Payment tampering, CSRF on callback
Copernica	REST API	Outbound	SSRF via newsletter opt-in
Algolia	REST API	Outbound	Data exfiltration via product index
TradeTracker	Feed / HTTP	Outbound	Feed manipulation

5.4 A/B testing mechanism¶

The platform runs an A/B test between the PrestaShop storefront and a newer frontend (brekz-website). PrestaShop sets an AB_templating cookie server-side and rewrites category links to www2.* subdomains when the cookie value is B. This cookie-based routing mechanism should be evaluated for:

Cookie tampering to force routing between environments
Differences in security controls between the two frontends

5.5 URL patterns¶

The PrestaShop admin is reachable at:

https://www.brekz.nl/administrator
https://www.brekz.be/administrator
[... same pattern for all 10 domains]

Product detail pages follow the pattern:

https://www.brekz.nl/index.php?controller=product&id_product={id}

6. Rules of Engagement¶

6.1 Testing hours¶

Rule	Detail
Active scanning / exploitation	Only outside Dutch business hours: Monday–Friday 09:00–18:00 CET is prohibited
Passive reconnaissance	May be performed at any time
Weekend testing	Permitted
Holiday restrictions	Check with contact if a Dutch public holiday falls within the test window

6.2 Prohibited actions¶

The following actions are strictly prohibited throughout the engagement:

Social engineering, phishing, or vishing of any Brekz or Flooris employee
Deleting, encrypting, or permanently modifying production data
Exfiltrating real customer PII outside of demonstrating a proof-of-concept (capture a sample, do not export in bulk)
Modifying order statuses, payment records, or financial data on production
Placing or completing real orders on production environments
Interfering with the Beanstalkd job queue in production
Accessing or modifying cron job schedules
Attacking out-of-scope third-party services

6.3 Test accounts¶

Brekz will provide the following test accounts before the engagement starts:

[TBD] — Customer account (registered user) with order history
[TBD] — Customer account (guest / unverified)
[TBD] — PrestaShop admin account (restricted role, read-only) — if agreed

The security specialist may use these accounts for authenticated testing. Creating additional accounts on production is permitted for testing purposes; created accounts must be reported in the final deliverable so they can be cleaned up.

6.4 Escalation protocol¶

If a critical vulnerability is discovered that poses an immediate risk (e.g., unauthenticated RCE, active exploitation by a third party, reachable admin credentials), the security specialist must:

Stop exploitation immediately and not proceed further with that attack vector.
Notify the primary contact (see below) within 1 hour via phone.
Document the finding with enough detail for immediate remediation.
Continue testing other areas while the critical finding is being triaged.

7. Points of Contact¶

Role	Name	Phone	Email
Primary technical contact	`[TBD]`	`[TBD]`	`[TBD]`
Secondary / emergency contact	`[TBD]`	`[TBD]`	`[TBD]`
Cloudflare unblocking	`[TBD]`	`[TBD]`	`[TBD]`
Hetzner abuse unblocking	`[TBD]`	`[TBD]`	`[TBD]`

The primary technical contact must be reachable by phone during all active testing windows. If the contact is unavailable, testing must pause until a contact is reachable.

8. Suggested Focus Areas¶

Based on the architecture and known risk factors, the following areas are recommended as high-priority focus points. This is guidance, not a limitation — the security specialist is free to pursue any in-scope vector.

EOL runtime vulnerabilities

PHP 7.2 and PrestaShop 1.6 have numerous published CVEs. Review NVD / Exploit-DB for known unpatched vulnerabilities in the exact installed versions.

Admin panel exposure

/administrator is reachable from the public internet without IP restriction. Evaluate brute-force protection, lockout policy, 2FA availability, and default/weak credentials.

SQL injection

PrestaShop 1.6 has a history of SQLi vulnerabilities in core and modules. Test all dynamic query parameters, especially in search, product filters, and order views.

File upload and RCE

Module installation, image upload, and theme upload endpoints may allow arbitrary file upload leading to remote code execution.

Cloudflare WAF bypass

Test whether WAF rules can be evaded using encoding, HTTP smuggling, or protocol-level tricks. Cache poisoning via crafted Host or X-Forwarded-Host headers.

Session and cookie security

Evaluate cookie flags (HttpOnly, Secure, SameSite), session fixation, session hijacking via the AB_templating A/B cookie, and token predictability.

Cross-environment contamination

Production, Test, and Acceptance share one physical server. Investigate whether a compromise of the Test/Acceptance environment can escalate to the production environment (shared filesystem, database, process namespace).

SOAP/XML injection (DPD)

The DPD integration uses SOAP. If any inbound SOAP response data is reflected into the application without sanitisation, test for XXE and XML injection.

Payment callback tampering

Docdata sends HTTP callbacks to confirm payment status. Test whether the callback endpoint validates authenticity ( HMAC, IP whitelist) or can be replayed/forged to mark unpaid orders as paid.

Server hardening

Port scan the origin IP. Check for exposed management services (SSH on default port, phpMyAdmin, Beanstalkd on port 11300, MySQL on port 3306), outdated OS packages, and weak SSH configuration.

9. Deliverables¶

The engagement must produce the following deliverables within [TBD] days after the end of the testing window:

Deliverable	Format	Description
Executive Summary	PDF	Non-technical overview of findings and overall risk rating, suitable for management
Technical Report	PDF	Full report with all findings, reproduction steps, and CVSS v3.1 scores
Proof-of-Concept artifacts	ZIP	Screenshots, HTTP request/response captures, scripts used (sanitised)
Remediation Recommendations	Section in report	Prioritised list of fixes, grouped by severity (Critical / High / Medium / Low / Informational)
Retest confirmation	Email	After Brekz applies critical/high fixes, the specialist confirms whether the fixes are effective (one retest cycle included)

Severity classification¶

Severity	CVSS v3.1	Expected remediation SLA
Critical	9.0 – 10.0	Immediate (within 24 hours of report)
High	7.0 – 8.9	Within 7 days
Medium	4.0 – 6.9	Within 30 days
Low	0.1 – 3.9	Next scheduled maintenance
Informational	N/A	At discretion of Brekz

10. Open Items Before Engagement Start¶

The following items must be completed and confirmed in writing before the security specialist begins active testing: