Anatomy of risks of a multi-tenant ticketing platform for tourist attractions — a case study of Orientarium Zoo Łódź

TL;DR. On April 3, 2026, the editorial team of Signal Dadalo Media conducted a controlled test of purchasing a ticket to Orientarium Zoo Łódź via the BASE platform — a multi-tenant SaaS ticket sales system serving (according to the operator’s declaration) over 50 facilities: zoos, water parks, ski resorts, UNESCO sites, hotels, and public institutions. The material below is an extended version of the notification submitted to UODO on April 23, 2026 — 18 days ago. During this time, ORIENTARIUM rebuilt the cart and modified the communication about partners and the payment procedure (analysis of payloads after modifications is still ongoing). The server still remains in the zone managed by Oracle (DynDNS, homelinux.net), so the hard architectural core remains unchanged.

Four cardinal sins

1. Low-trust DynDNS domain infrastructure (homelinux.net, Oracle Dyn zone — a Dynamic DNS / Remote Access service for home devices).
2. Extremely outdated server software — nginx/1.10.3 on Ubuntu 16.04, which saw standard security support end in 2021, and ESM expires in April 2026.
3. Critically incorrect CORS configuration — Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true, contradicting the W3C/WHATWG Fetch specification.
4. Passing personal data in URL parameters (GET) — the customer’s email address as CustomerEmail in the query string of the redirect to the payment operator.

In a typical security audit or GDPR compliance check, this setup would receive a negative rating with a recommendation for immediate migration to a more secure architecture.

I. FACTUAL STATUS

On April 3, 2026, the editorial team undertook verification activities regarding the electronic ticket sales architecture in the BASE platform, using the process of purchasing an entry ticket to Orientarium Zoo Łódź as an example. The test was conducted under controlled conditions — in a browser in private mode, without cache and previously saved cookies — using the editorial identity (email address: redakcja@dadalo.pl). The goal was to verify the platform’s behavior in a typical purchase scenario and to document how personal data is processed during this process.

Complete technical documentation was collected:

• łańcuch przekierowań HTTP z surowymi nagłówkami odpowiedzi serwerów,
• odtwarzalne zapytania curl odwzorowujące przepływ zakupu,
• pełną konfigurację CORS zwracaną na żądania preflight OPTIONS,
• rozpoznanie DNS dla wszystkich domen w łańcuchu,
• ciasteczka ustawiane w toku procesu zakupu,
• żądania do systemów analitycznych aktywnych na stronie bramki płatniczej,
• nagłówki SMTP wiadomości e-mail wygenerowanej przez system po transakcji.

The entire technical material is located in Section V (Attachments).

I.1. Sales system architecture — external component embedded on the Administrator’s site

The orientarium.lodz.pl/bilety site does not host the sales panel in its own infrastructure. The purchase form is a web component embedded from an external system operating under the sklep.homelinux.net domain. Personal data entered by the user — first name, last name, email address, phone number — goes directly to the server at IP address 185.204.217.182, and not to the Administrator’s infrastructure.

This model is publicly described by the platform operator as the standard deployment mode. On the basesystem.pl/modul-sprzedazy-online page, BASE declares: „The online sales panel can be placed inside your own website after configuring tickets, graphics, and color accents", further stating: „To make a purchase, just select tickets, confirm the order by providing your name, surname, and email address, and then pay for the order online".

Browser communication with the backend occurs through API endpoints identified by unique GUIDs at the URL path level:

POST https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add
POST https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/order

The string f5ff01a4311c42a68af6f4d9780290d2 is the tenant identifier (GUID) of a specific platform client — in the described case, Orientarium Zoo Łódź. The endpoint structure confirms the multi-tenant nature of the system: the identical infrastructure serves many data administrators under different identifiers.

I.2. Exposure of the customer’s email address in the URL parameter — the main violation

After placing the order and clicking the “Buy and pay” button, the sklep.homelinux.net server generates an HTTP redirect, directing the user’s browser to the payment operator. Reproducibly captured server response headers:

1
2
3
4
5
6
7

HTTP/1.1 302 Found
Server: nginx/1.10.3 (Ubuntu)
Location: https://pay.bm.pl/payment?ServiceID=103573
  &OrderID=7a31bf54b0434ed8827c2669eb01505c
  &Amount=80.00
  &CustomerEmail=redakcja@dadalo.pl
  &Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027

The customer’s email address — the CustomerEmail parameter — is passed in the URL query string (GET method), in plain text. The email address in the URL is exposed in the following processing contexts:

• in the browser address bar — visible to third parties with a view of the screen;
• in the browser history — permanently saved and synchronized between devices by Chrome Sync, Firefox Sync, etc.;
• in server access logs — both sklep.homelinux.net and pay.bm.pl, and then pay.autopay.eu standardly register the full URL (including the query string) in logs, unless the administrators of these systems have implemented dedicated filtration;
• in the Referer HTTP header — subsequent HTTP requests may pass the URL containing personal data to third-party systems;
• in analytical systems active on the payment gateway — Matomo (piwik.blue.pl) and Google Analytics, as described in Section I.9.

Industry standards — including OWASP recommendations for „Use of Sensitive Information in URL Query Parameters" (CWE-598) and educational materials from the payment operator Autopay itself — clearly state that personal data should be passed in the body of a POST request or via a server-to-server channel, and never in a URL query string.

The described processing pattern is not an individual configuration error, but a systemic solution in the BASE ↔ pay.bm.pl integration. This is indicated by both the URL parameter structure (containing a cryptographic Hash calculated on the BASE server based on parameters, including CustomerEmail) and the consistent appearance of the parameter in each subsequent test.

I.3. Outdated server infrastructure — nginx 1.10.3 on Ubuntu 16.04

The server serving the BASE platform responds with the header:

Server: nginx/1.10.3 (Ubuntu)

Nginx version 1.10.3 was released on January 31, 2017. The 1.10 upstream branch ended support in 2017. This package comes from the Ubuntu 16.04 LTS (Xenial Xerus) distribution, which:

• standard security support from Canonical ended in April 2021 (five years before the audit date);
• extended support (Extended Security Maintenance, ESM) — available as a paid subscription under Ubuntu Pro — lasts until the end of April 2026, meaning it expires within the next few days.

This means that the infrastructure processing the personal data of customers of dozens of public utility facilities and handling payment initiations worth millions annually:

• over the last five years has only received security updates narrowly limited to CVEs with high and critical risk levels (under ESM), provided the operator had an active, paid Ubuntu Pro subscription;
• within the next few days will stop receiving any updates from the operating system manufacturer, unless the operator acquires an additional “Legacy” Ubuntu Pro subscription;
• has not received updates from nginx upstream for years (the 1.10 branch ended its life cycle in 2017);
• does not provide support for current TLS protocol standards or newer HTTP/2 protection mechanisms.

Migration to a supported version of the operating system distribution is a routine process, available to any professional IT infrastructure operator.

I.4. Incorrect CORS configuration — contradiction with W3C specification

The shop’s API server responds to the preflight request (OPTIONS) with the following headers:

1
2
3
4
5
6
7
8

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,
  X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,
  Expires,Pragma
Access-Control-Max-Age: 1728000

The simultaneous occurrence of Access-Control-Allow-Origin: * (wildcard) and Access-Control-Allow-Credentials: true is a configuration contrary to the CORS specification (W3C / WHATWG Fetch Standard — section on credentialed requests). The specification explicitly states that when the credentials flag is set to true, the Access-Control-Allow-Origin value must indicate a specific source, not a wildcard. While standard browser implementations will block such requests at the client level, the server’s declaration of accepting authenticated requests from any source shows a lack of security review and signals that the server was configured in a way inconsistent with basic web security standards.

For comparison: the Matomo analytical system operating under the piwik.blue.pl domain (used on the pay.autopay.eu gateway) uses a precise Access-Control-Allow-Origin: https://pay.autopay.eu restriction. The operator of the BASE ticketing system does not apply any source restriction.

I.5. Production domain in a zone managed by Oracle Corporation — homelinux.net

The system processing customer personal data and handling payment initiation operates under the sklep.homelinux.net subdomain. The homelinux.net zone is a dynamic DNS domain offered by Dyn — an entity acquired by Oracle Corporation in 2016. This is confirmed by the DNS reconnaissance performed on April 21, 2026:

$ dig SOA homelinux.net
→ ns1.dyndns.org. hostmaster.dyndns.org. 2126617188 10800 1800 604800 1800

The homelinux.net zone is on the official list of Oracle/Dyn dynamic DNS domains (publication: help.dyn.com/list-of-dyn-dns-pro-remote-access-domain-names.html), alongside domains such as is-a-chef.com, is-a-geek.com, homeunix.com, and homeip.net. According to the official description of the Oracle Dyn Dynamic DNS service, its application is for „remotely accessing files from home computers, monitoring security systems, and accessing home…" — remote access to home devices (NAS, security camera, router, hobby server). The public description of the Oracle Dyn service shows that it is a Dynamic DNS / Remote Access solution, intended for binding a changing IP address with devices and services such as a router, camera, DVR, thermostat, computer, file storage, or game server.

Importantly, BASE does not act as the entity managing the homelinux.net zone, but as a user of a subdomain functioning within the Oracle Dyn infrastructure, which is confirmed by DNS findings and the description of this service. This means that the operator does not exercise decisive control over the authoritative servers of this zone, its delegation parameters, or the policy for maintaining the zone itself by the service provider. For the sklep.homelinux.net address, there is no separate WHOIS registration, as the registration applies to the homelinux.net domain, not its subdomains.

Consequently, the DNS layer from which personal data processing and payment initiation services are actually provided remains embedded in an external zone over which the operator does not exercise full administrative control. This is significant not only from the point of view of current infrastructure management but also from the perspective of business continuity and predictability of the terms of service by a third party.

Additional context: BASE simultaneously uses its own domain basesystem.pl, which justifies the question of whether the adopted addressing model was a properly designed solution for a production environment of this scale.

I.6. Lack of infrastructure segmentation, DMARC p=none and phishing risk

Following the test purchase to the address redakcja@dadalo.pl, an email arrived from a sender displayed as “ZOO Łódź” — from the actual address noreply@basesystem.pl. Analysis of the SMTP headers reveals:

Received: from [127.0.0.1] (unknown [185.204.217.182])
  (Authenticated sender: noreply@basesystem.pl)
  by ewok.endor.pl (Postfix) with ESMTPSA id...

Analysis of the full SMTP headers of the transactional message indicates that final delivery to the recipient took place through the server ewok.endor.pl (91.194.229.47), whereas the host 185.204.217.182 — associated with the infrastructure of sklep.homelinux.net — authenticated to that server as an SMTP client with the identifier noreply@basesystem.pl.

This means that the application layer responsible for handling the shop participates directly in generating and authenticating outbound transactional correspondence; consequently, compromise of this host could translate into abuse of the sending channel or of the SMTP mechanism used to communicate with customers.

The headers do not, however, permit a direct claim that the same machine delivers mail to recipients on its own or retains the full history of sent messages, since a separate mail relay participates in the process.

At most a partial segmentation has been applied — one that does not isolate the application host from authenticated SMTP submission.

A further factor lowering the level of protection is the DMARC policy of the basesystem.pl domain, set to p=none. This means that recipient mail servers take no blocking action against spoofed messages impersonating basesystem.pl. Combined with the fact that:

• the content of transactional emails is straightforward to reproduce (first name, last name, email address, ticket name, amount);
• the displayed sender (friendly name) can be set arbitrarily to a name familiar to the recipient (“ZOO Łódź”);
• the recipient does not expect a message from the basesystem.pl domain, which is not disclosed at any point in the purchase process;
• the system does not offer sending from a branded (white-label) domain — i.e. from a subdomain of the Controller (e.g. no-reply@orientarium.lodz.pl) — which is a widely recognised good practice in professional ticketing systems,

this creates a phishing attack vector of high credibility. Documented attacks exist that exploit exactly this set of information (order number, venue name, amount, customer’s first and last name) against users of reservation systems. The most recent such attack targeted customers of the KWhotel system.

I.7. Instability of the payment initiation process

During HTTP traffic capture, it was observed that the first attempt to initiate a redirect to the payment gateway ended with an HTTP 500 Internal Server Error response code:

1
2
3
4
5
6
7

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, private
date: Fri, 03 Apr 2026 10:02:23 GMT
Set-Cookie: XSRF-TOKEN=[...]
Set-Cookie: base_system_session=[...]

Despite the internal error, the server continued processing the transaction (setting session cookies and finally generating another redirect). Such behavior suggests a lack of proper error handling in the critical path of the payment process. This creates a risk of uncontrolled data leakage to server error logs (e.g., stack traces containing variable values, including the customer’s personal data), and also makes subsequent auditing difficult — events occur in the logs without clear mapping to the processing state.

I.8. Cookies without the Secure flag

Cookies set by the sklep.homelinux.net server do not contain the Secure flag:

1
2

Set-Cookie: XSRF-TOKEN=[...]; expires=[...]; Max-Age=7200; path=/
Set-Cookie: base_system_session=[...]; expires=[...]; Max-Age=7200; path=/; httponly

The XSRF-TOKEN cookie has neither the Secure nor the HttpOnly flag. The base_system_session cookie only has HttpOnly. The lack of the Secure flag means that in the event of an unsecured communication channel (e.g., degradation to HTTP, error in the certificate chain), cookies can be transmitted in unencrypted form. For sessions containing customer personal data processing identifiers, this is a violation of basic web security standards. This may also result from outdated and unupdated server software.

I.9. Analytics and recording of the user’s session on the payment gateway page

After passing through the redirect chain, the user arrives at the pay.autopay.eu/web/payment/start/{GUID} page, where they select a payment method. Analytical systems recording the user’s behavior are active on this page:

Matomo (piwik.blue.pl, idsite=47) — during the test, six requests to this domain were recorded, including:

• loading the piwik.js script;
• registering a page view with the full gateway URL as the url parameter;
• activation of the HeatmapSessionRecording module (/plugins/HeatmapSessionRecording/configs.php?idsite=47&trackerid=Zn1V3x) — recording the user’s session, registering mouse movements, clicks, and scrolling;
• activation of the AB Testing module (e_c=abtesting&e_a=SimpleABTest);
• activation of the Ecommerce tracking module (_pkp=80&_pks=2&_pkn=ECOMMERCE) with information about the transaction value.

Google Analytics — POST request to www.google-analytics.com/mp/collect?measurement_id=G-CFLZGNHGSQ — tracking via the Measurement Protocol.

Recording a user’s session (HeatmapSessionRecording) on a page where the user selects a payment method and enters payment card data is a high-risk practice. Regardless of the masking mechanisms implemented by the operator, the mere fact of registering user interactions in real-time — combined with the possibility of the URL containing CustomerEmail in the Referer header from the previous step of the chain — raises serious doubts about the scope and legal basis of the processing.

I.10. Multi-tenant platform serving dozens of entities - scale of the deployment pattern

The described technical findings do not concern a single, local deployment. BASE is a reusable SaaS platform. On the basesystem.pl/realizacje page, the operator publicly lists over 50 objects using the platform. The list is mentioned sectorally only as an indication of the scale of the deployment pattern, which — if the technical findings described in sections I.2–I.9 are systemic (and their nature suggests so) — potentially affects all data administrators using the same infrastructure:

Amusement parks, Zoos, Water parks and pools, Ski resorts, UNESCO and cultural sites, Hotels and SPAs, Public institutions, Ice rinks.

The editorial team did not verify deployments on the websites of the listed entities for legal reasons and the lack of possibility of reliable and quick verification — we do not present a full list of companies. Especially since the list of implementations on the contractor’s website may be outdated (e.g., EnergyLandia uses comarchesklep.pl to handle online ticket sales). However, we point out that all these entities may be using the same server (IP 185.204.217.182), the same software version, the same CORS configuration, and the same model of passing data to the payment operator — which suggests that the observed deficiencies may be a repeatable deployment pattern of a nationwide character.

I.11. Inconsistency of the Sales Regulations and Cookie Policy with the actual processing status

The editorial team analyzed the Regulations for the electronic sale of entry tickets to Orientarium Zoo Łódź (available at orientarium.lodz.pl/bilety) and the Cookie Policy of the orientarium.lodz.pl service (available on the same page). These documents show significant inconsistencies with the actual status of personal data processing, as established in sections I.1–I.9:

(a) Lack of information about the BASE processor. The Regulations in point V.6 declare the categories of data recipients as follows: „entities providing and supporting teleinformatic systems, entities providing services to the Administrator, e.g., accounting, legal, the entity providing online payment services". The category “entities providing and supporting teleinformatic systems” is so general that it does not allow the data subject to identify a specific processor. Neither the Regulations nor the Cookie Policy mention the BASE operator (basesystem.pl) and the sklep.homelinux.net domain, even though this entity and this domain are the actual recipients of the customer’s personal data at the time of filling out the purchase form.

(b) Outdated name of the payment operator. The Regulations in point III.9 indicate the payment operator as „Blue Media S.A. with its registered office in Sopot". This company changed its name to “Autopay S.A.” in 2022. The Regulations have not been updated. Although this deficiency is informational in nature, it shows a lack of ongoing verification of GDPR documentation by the Administrator.

(c) Declaration of no automated processing contrary to the actual status. The Regulations in point V.9 explicitly declare: „We inform you that the Customer’s data will not be processed in an automated way, including profiling." Meanwhile — as shown in Section I.9 — on the pay.autopay.eu payment gateway page, to which the customer is redirected, Matomo systems with HeatmapSessionRecording (session recording) and AB Testing modules, as well as Google Analytics, are active. These are forms of automated registration and analysis of user behavior. The Administrator’s declaration thus misleads the data subject as to the actual scope of processing.

(d) Lack of information about analytical systems in the purchase chain. The Cookie Policy lists the Administrator’s partners in terms of external cookies (Facebook, LinkedIn, Twitter, YouTube, Google Analytics). It does not mention either piwik.blue.pl (Matomo of the payment operator active during the purchase process) or any tracking related to the sklep.homelinux.net domain. The data subject thus does not receive full information about the systems in the context of which their behavior is recorded during the ticket purchase process.

(e) Generality of declarations about external recipients. The Regulations in point V.10 declare: „Personal data will not be transferred to a third country or other entities, except for those that are entitled to obtain them on the basis of applicable law." This declaration does not take into account the fact that customer data during payment initiation is transferred in the URL address to the pay.bm.pl domain, and then to pay.autopay.eu, where it is registered by Matomo and Google Analytics systems (the latter with a flow of data to Google LLC in the USA — a third country under GDPR).

I.12. Karta Łodzianina — a classic input validation failure in a separate purchase mechanism

Independent of the standard ticket purchase process described above, there is a separate mechanism in the service for handling tickets associated with loyalty cards (including the Karta Łodzianina implemented by QB sp. z o.o. from Gdynia). This mechanism uses a separate form to verify eligibility for a discount, in which the user provides the card number and PIN code, and then initiates the eligibility check by an external backend operating at sklep.homelinux.net.

During the verification of this mechanism, a lack of effective validation of the length of the input data in the card number field and a lack of sanitization of special characters were found — a textbook input validation failure from the OWASP Top 10 catalog (“Insecure Design” / “Injection” category). Endpoint:

POST /api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/useService

allowed sending a card field value of a size far exceeding a rational card number format, with special characters — which could lead to a disruption of the verification form and indicates a lack of elementary input restrictions on the part of the application and/or backend. In the screenshots (Attachment R), the lack of length restriction for data in the card number field and the acceptance by the system of a string with a length of » 1000 characters is visible, which confirms the lack of basic sanitization and input validation.

Why this is important:

• the mechanism for verifying eligibility for a discount is implemented by the same BASE infrastructure (sklep.homelinux.net) that also mediates in other ticket purchase operations and user data processing;
• the lack of basic input validation mechanisms in a separate channel for handling discounts and loyalty cards indicates significant flaws in the design and security of this solution, which could constitute a potential attack vector on the infrastructure and the personal data processed therein;
• the nature of the deficiency (lack of length validation and input sanitization) is among the basic classes of web application security risks identified in OWASP and ENISA guidelines as requiring mandatory control at the design stage.

Under the eligibility verification form, there is a message: „In case of questions related to the offer, please contact us at bok@zoo.lodz.pl. The ticket sales system is provided by BASE System". The juxtaposition of this message with the actual flow of requests to sklep.homelinux.net confirms that the operation of checking eligibility for a discount does not take place exclusively in the Administrator’s infrastructure, but with the participation of an external intermediary server.

The test was conducted solely using the standard functionality of the publicly available form, on the editorial team’s test identity (redakcja@dadalo.pl), without using any automation tools, without attempting code injection, without violating system integrity, or bypassing authentication mechanisms. The action consisted of entering a string of characters in the card number field exceeding a rational format, which the system accepted, revealing a lack of input validation. There was no disruption to the system’s operation or access to unauthorized data.

V. TECHNICAL ATTACHMENTS

Documentation collected during the controlled purchase test conducted on April 3, 2026 (Audit ID evidence_20260403_1149).

Attachment A — redirect_chain.json

HTTP redirect chain recorded with URL containing CustomerEmail parameter:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[
  {
    "url": "https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c",
    "status": 302,
    "location": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027"
  },
  {
    "url": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027",
    "status": 303,
    "location": "https://pay.autopay.eu/web/payment/start/768a3653b0da481699fe1e6c496eeeeb"
  }
]

Attachment B — redirect_chain_raw_headers.txt

Raw HTTP headers from server responses, including recorded HTTP 500 Internal Server Error code:

=== Payment Redirect Chain Capture ===
Timestamp: 2026-04-03T10:02:23Z
Order GUID: 7a31bf54b0434ed8827c2669eb01505c
Initial URL: https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c
=======================================

--- Step 1: Payment Init (sklep.homelinux.net) ---
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Cache-Control: no-cache, private
date: Fri, 03 Apr 2026 10:02:23 GMT
Set-Cookie: XSRF-TOKEN=eyJpdiI6Ing5c09DWUZpbUJ2eFF1bXpzMU5ISHc9PSIsInZhbHVlIjoieDBZVHdlQzlLaWJnQWtXMGloRFJsaWk1TFF2bnpnL2lKQ0I1dnZVMktEUkxYZUh1V3c1S2J6UlJiYzFQdVdkVXBQS09UemowNDBPcmtoSDNQbnZBRVMrSndzdTJPajRDRm0yR1NUMkQxcXJ1VGFkN2lDWDVHaFBucld6THE0NXMiLCJtYWMiOiI3ODIwY2Y0YzQ1NmQ0MWNkOTAyODcwYmI5NjMyNWVlOWE1NTc1OGNmODQ0ZDFkYjNlNDhlMGI3MGMyZTk0YzVkIn0%3D; expires=Fri, 03-Apr-2026 12:02:23 GMT; Max-Age=7200; path=/
Set-Cookie: base_system_session=eyJpdiI6IklobzNJNE5xTzU3WWZJQThRTmRmbmc9PSIsInZhbHVlIjoieTRFTU16WlBzeXNVblJ2WU4rei9VWnpPdjJUZDBYMzgzQ1VRdXRDMEk3R3ppVGJ5bmhRcndMNGV1VTVlRk05cGtRZUlyZGkwTWwwMXlXVm1COHNwTWNHeG9kdFZ3NjF1MjZhRmdQL242bVJrZzZhRlpoU2ZPbkFMSjdzeU9xYm8iLCJtYWMiOiI3MDdmN2YyMDRiMDg4YmZlOGU5OGFmNTY3ODdhZDQwYjYzMDYxNDVhZjVlZDVhMzc2ZTI2ZTM3MmNkZWFmZjBhIn0%3D; expires=Fri, 03-Apr-2026 12:02:23 GMT; Max-Age=7200; path=/; httponly

Attachment C — redirect_chain_curl.json

Reproducible version of the redirect chain in the form of curl queries:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "capture_timestamp": "2026-04-03T10:02:23Z",
  "order_guid": "7a31bf54b0434ed8827c2669eb01505c",
  "redirect_chain": [
    {
      "step": 1,
      "url": "https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c",
      "status": "302",
      "location": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027",
      "server": "nginx/1.10.3 (Ubuntu)",
      "description": "Payment init on sklep.homelinux.net - 302 redirect exposes CustomerEmail in URL"
    },
    {
      "step": 2,
      "url": "https://pay.bm.pl/payment?ServiceID=103573&OrderID=7a31bf54b0434ed8827c2669eb01505c&Amount=80.00&CustomerEmail=redakcja@dadalo.pl&Hash=f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027",
      "status": "303",
      "location": "https://pay.autopay.eu/web/payment/start/768a3653b0da481699fe1e6c496eeeeb",
      "description": "Payment gateway redirect (pay.bm.pl → pay.autopay.eu)"
    },
    {
      "step": 3,
      "url": "https://pay.autopay.eu/web/payment/start/768a3653b0da481699fe1e6c496eeeeb",
      "status": "200",
      "location": null,
      "description": "Autopay payment page (STOP - do not proceed with payment)"
    }
  ],
  "pii_in_url": true,
  "customer_email_extracted": "redakcja@dadalo.pl"
}

Attachment D — cors_check.txt

Server response to OPTIONS preflight request confirming CORS wildcard + credentials configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

HTTP/1.1 204 No Content
Server: nginx/1.10.3 (Ubuntu)
Date: Fri, 03 Apr 2026 10:02:26 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,Expires,Pragma
Access-Control-Max-Age: 1728000
Content-Type: text/plain charset=UTF-8
Content-Length: 0

Attachment E — api_calls.json

Record of API calls indicating the nginx version in response headers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

[
  {
    "direction": "request",
    "method": "OPTIONS",
    "url": "https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add",
    "headers": {
      "Origin": "https://orientarium.lodz.pl",
      "Access-Control-Request-Method": "POST"
    },
    "timestamp": "2026-04-03T10:02:26Z"
  },
  {
    "direction": "response",
    "method": "OPTIONS",
    "url": "https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add",
    "status": 204,
    "server": "nginx/1.10.3 (Ubuntu)",
    "cors_origin": "*",
    "cors_credentials": "true",
    "findings": [
      "CORS wildcard origin (*) - accepts any origin",
      "CORS credentials (true) combined with wildcard - spec violation",
      "nginx/1.10.3 (Ubuntu) - released January 2017, EOL, multiple known CVEs"
    ]
  },
  {
    "direction": "response",
    "method": "GET",
    "url": "https://sklep.homelinux.net/payments/bluemedia/pay/7a31bf54b0434ed8827c2669eb01505c",
    "status": 302,
    "server": "nginx/1.10.3 (Ubuntu)",
    "findings": [
      "302 redirect exposes CustomerEmail in URL query string - PRIMARY EVIDENCE",
      "XSRF-TOKEN cookie set WITHOUT Secure flag",
      "base_system_session cookie set WITHOUT Secure flag, has httponly only"
    ]
  }
]

Attachment F — cookies.json

Cookies set in the purchase and payment chain (including lack of Secure flag):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "pay.autopay.eu": {
    "layout": "light",
    "_pk_id.47.1dc5": "c3d4b4d5c6760351.1775210441.",
    "_pk_ses.47.1dc5": "1",
    "lang": "PL"
  },
  "sklep.homelinux.net": {
    "XSRF-TOKEN": "eyJpdiI6Ing5c09DWUZpbUJ2eFF1bXpzMU5ISHc9PSIs...",
    "base_system_session": "eyJpdiI6IklobzNJNE5xTzU3WWZJQThRTmRmbmc9PSIs..."
  },
  "assets.secure.checkout.visa.com": {
    "_cfuvid": "mOY9m4UFlc6aHLeSgh.yyamFrgSqFLAu4ecMH6YDXs0-1775210441910-0.0.1.1-604800000"
  }
}

Attachment G — dns_resolution.txt

DNS reconnaissance for all domains in the chain, including SOA homelinux.net indicating zone management by Oracle/Dyn and information about sklep.homelinux.net TLS certificate:

=== DNS Resolution Report ===
Timestamp: 2026-04-21T19:22:10Z
==============================

--- sklep.homelinux.net ---
# dig +short sklep.homelinux.net
185.204.217.182

--- orientarium.lodz.pl ---
# dig +short orientarium.lodz.pl
49.12.241.238
# dig NS orientarium.lodz.pl
dns.home.pl.
dns2.home.pl.
dns3.home.pl.
# dig -x 49.12.241.238 (reverse DNS)
static.238.241.12.49.clients.your-server.de.

--- pay.bm.pl ---
# dig +short pay.bm.pl
195.187.130.220
# dig -x 195.187.130.220 (reverse DNS)
h220.blue.pl.

--- pay.autopay.eu ---
# dig +short pay.autopay.eu
195.187.130.220
# dig -x 195.187.130.220 (reverse DNS)
h220.blue.pl.

--- piwik.blue.pl ---
# dig +short piwik.blue.pl
k8s-servicesexternal-1dcca797e8-1429967.eu-west-1.elb.amazonaws.com.
3.248.18.229
63.32.37.232
54.171.230.184

=== DynDNS check for homelinux.net ===
# dig SOA homelinux.net
ns1.dyndns.org. hostmaster.dyndns.org. 2126617188 10800 1800 604800 1800

=== TLS Certificate: sklep.homelinux.net ===
subject=CN=sklep.homelinux.net
issuer=C=US, O=Let's Encrypt, CN=R13
notBefore=Mar 30 06:52:26 2026 GMT
notAfter=Jun 28 06:52:25 2026 GMT
serial=06C33635D303101CA1C536B42E7A1F933D2D

=== Server headers: sklep.homelinux.net ===
HTTP/1.1 302 Found
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Cache-Control: no-cache, private
Date: Tue, 21 Apr 2026 19:22:11 GMT
Location: https://sklep.homelinux.net/login

Attachment H — matomo_requests.json

Requests to analytical systems (piwik.blue.pl and Google Analytics) active on the payment gateway, including activation of the HeatmapSessionRecording module:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

[
  {
    "url": "https://piwik.blue.pl/piwik.js",
    "method": "GET",
    "referer": "https://pay.autopay.eu/"
  },
  {
    "url": "https://piwik.blue.pl/piwik.php?action_name=pay.autopay.eu%2FBramka%20p%C5%82atnicza%20-%20Autopay&idsite=47&rec=1&r=066307&h=12&m=0&s=41&url=https%3A%2F%2Fpay.autopay.eu%2Fweb%2Fpayment%2Fstart%2F768a3653b0da481699fe1e6c496eeeeb",
    "method": "POST",
    "referer": "https://pay.autopay.eu/",
    "notes": "Main page view tracking"
  },
  {
    "url": "https://piwik.blue.pl/plugins/HeatmapSessionRecording/configs.php?idsite=47&trackerid=Zn1V3x&url=https%3A%2F%2Fpay.autopay.eu%2Fweb%2Fpayment%2Fstart%2F768a3653b0da481699fe1e6c496eeeeb",
    "method": "GET",
    "referer": "https://pay.autopay.eu/",
    "notes": "Heatmap and Session Recording Active"
  },
  {
    "url": "https://piwik.blue.pl/piwik.php?e_c=abtesting&e_a=SimpleABTest&e_n=NO_SUBMIT&ca=1&idsite=47...",
    "method": "POST",
    "referer": "https://pay.autopay.eu/",
    "notes": "AB Testing tracking"
  },
  {
    "url": "https://piwik.blue.pl/piwik.php?action_name=pay.autopay.eu%2FBramka%20p%C5%82atnicza%20-%20Autopay...&_pkp=80&_pks=2&_pkn=ECOMMERCE...",
    "method": "POST",
    "referer": "https://pay.autopay.eu/",
    "notes": "Ecommerce tracking for 80 PLN"
  },
  {
    "url": "https://www.google-analytics.com/mp/collect?measurement_id=G-CFLZGNHGSQ",
    "method": "POST",
    "referer": "https://pay.autopay.eu/"
  }
]

Attachment I — summary.json

Technical summary of the audit with key parameters (ServiceID, OrderID, tenant GUID, server IP, nginx version, CORS configuration):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "test_timestamp": "2026-04-21T21:24:45.459103",
  "test_identity_email": "redakcja@dadalo.pl",
  "pii_exposed_in_url": true,
  "pay_bm_url_params": {
    "ServiceID": "103573",
    "OrderID": "7a31bf54b0434ed8827c2669eb01505c",
    "Amount": "80.00",
    "CustomerEmail": "redakcja@dadalo.pl",
    "Hash": "f35e47d4e2203c22392f58b5b0d22e24270f14d2cd3e5d2d58f4770379c63027"
  },
  "service_id": "103573",
  "redirect_chain_length": 2,
  "matomo_analysis": {
    "matomo_count": 6,
    "pii_in_referer": false,
    "cross_tenant_refs": []
  },
  "cors_wildcard_detected": true,
  "cors_credentials_with_wildcard": true,
  "server_version": "nginx/1.10.3 (Ubuntu)",
  "tenant_guid": "f5ff01a4311c42a68af6f4d9780290d2",
  "sklep_homelinux_ip": "185.204.217.182",
  "infrastructure_findings": {
    "eol_server": true,
    "dyndns_domain": true,
    "cors_misconfiguration": true,
    "cookie_flag_issues": 0
  }
}

Attachment J — recon.json

Reconnaissance of the purchase form structure and UI elements of the embedded BASE component:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "embedding_model": "Web Component (sklep.homelinux.net)",
  "form_fields": {
    "email": "input[placeholder='Adres e-mail *']",
    "first_name": "input[placeholder='Imię *']",
    "last_name": "input[placeholder='Nazwisko *']",
    "phone": "input[placeholder='Telefon *']"
  },
  "buttons": {
    "add_to_cart": "div:has-text('Dodaj do koszyka')",
    "go_to_checkout": "button:has-text('Przejdź do kasy')",
    "accept_terms": "label:has-text('Zapoznałem się z Regulaminem')",
    "pay": "div:has-text('Kupuję i płacę')"
  },
  "observations": {
    "cart_location": "Right-side panel (visible after adding item)",
    "checkout_trigger": "Right-side panel form replaces cart view.",
    "shadow_dom": "Likely used as it is a web component from homelinux.net"
  }
}

Attachment L — SMTP Headers

Email message from noreply@basesystem.pl confirming the sender IP identity and DMARC p=none policy:

Return-Path: <noreply@basesystem.pl>
Authentication-Results: mail.protonmail.ch; dkim=pass (Good 1024 bit rsa-sha256 signature) header.d=basesystem.pl
Authentication-Results: mail.protonmail.ch; dmarc=pass (p=none dis=none) header.from=basesystem.pl
Authentication-Results: mail.protonmail.ch; spf=pass smtp.mailfrom=basesystem.pl

Received: from [127.0.0.1] (unknown [185.204.217.182])
    (Authenticated sender: noreply@basesystem.pl)
    by ewok.endor.pl (Postfix) with ESMTPSA id C806E202028F
    for <redakcja@dadalo.pl>; Fri, 3 Apr 2026 12:00:56 +0200 (CEST)

Received: from ewok.endor.pl (ewok.endor.pl [91.194.229.47])
    by mailinzur1020.protonmail.ch (Postfix) with ESMTPS id 4fnDkn3YmPz9vNQ5
    for <redakcja@dadalo.pl>; Fri, 3 Apr 2026 10:01:05 +0000 (UTC)

Message-Id: <99a1f65733393982d2a7331b70df08de@swift.generated>
Date: Fri, 03 Apr 2026 12:00:55 +0200
Subject: =?utf-8?Q?Potwierdzenie_z=C5=82o=C5=BCenia_zam=C3=B3wienia.?=
From: =?utf-8?B?Wk9PIMWBw7Nkxbo=?= <noreply@basesystem.pl>
Reply-To: =?utf-8?Q?ZOO_=C5=81=C3=B3d=C5=BA_<faktury@zoo.lodz.pl>?=

Other Attachments

• Attachment M — archived snapshot of the basesystem.pl/modul-sprzedazy-online page with the operator’s public declaration on how customer data is processed: https://archiv.dadalo.pl/archive/1776884876.012425/index.html
• Attachment N — archived snapshot of the basesystem.pl/realizacje page with the list of publicly declared platform clients: https://archiv.dadalo.pl/archive/1776945609.60861/index.html
• Attachment O — Regulations for the electronic sale of entry tickets to Orientarium Zoo Łódź (in force, downloaded from the orientarium.lodz.pl/bilety site): https://archiv.dadalo.pl/archive/1776884876.012425/index.html
• Attachment P — Cookie Policy of the orientarium.lodz.pl service (in force): https://archiv.dadalo.pl/archive/1772740908.024841/index.html
• Attachment R — screenshot of a ticket purchase using the Karta Łodzianina, documenting the lack of length validation for the card field.

Attachment S — Point verification on the day of publication

Performed on May 10, 2026, 00:37 CEST (22:37 UTC, May 9). Three reproducible queries confirming the maintenance of key infrastructure findings from April 3, 2026.

$ curl -sI https://sklep.homelinux.net/ | grep -i server
Server: nginx/1.10.3 (Ubuntu)

$ curl -s -X OPTIONS \
    https://sklep.homelinux.net/api/v1/f5ff01a4311c42a68af6f4d9780290d2/shop/cart/tickets/add \
    -H "Origin: https://orientarium.lodz.pl" \
    -H "Access-Control-Request-Method: POST" \
    -D - -o /dev/null
HTTP/1.1 204 No Content
Server: nginx/1.10.3 (Ubuntu)
Date: Sat, 09 May 2026 22:37:35 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,
  If-Modified-Since,Cache-Control,Content-Type,Authorization,Expires,Pragma
Access-Control-Max-Age: 1728000
Content-Type: text/plain charset=UTF-8

$ dig SOA homelinux.net
homelinux.net. 86400 IN SOA ns1.dyndns.org. hostmaster.dyndns.org.
  2126648047 10800 1800 604800 1800

Conclusions:

• I.3 — Server: nginx/1.10.3 (Ubuntu) unchanged. Server software released in January 2017, with ended upstream support and expiring Ubuntu ESM, remains in production.
• I.4 — Orientarium tenant API endpoint (GUID f5ff01a4311c42a68af6f4d9780290d2) returns preflight 204 No Content with Access-Control-Allow-Origin: * in combination with Access-Control-Allow-Credentials: true. Configuration contrary to W3C / WHATWG Fetch Standard unchanged.
• I.5 — the homelinux.net zone remains under the authority of ns1.dyndns.org. The zone serial number changed from 2126617188 (April 21) to 2126648047 (May 10), indicating active maintenance of the zone by Dyn, but not a change of operator or addressing layer.

The tenant GUID f5ff01a4311c42a68af6f4d9780290d2 remains active — the purchase endpoint was not moved during interface modifications.

All tests were conducted using the editorial team’s test identity (email address: redakcja@dadalo.pl). No data of actual system users was obtained or processed during the audit. The evidence was collected in a reproducible manner (reproducible curl queries, raw HTTP headers, DNS reconnaissance) and can be independently verified.

Postscriptum: status as of May 11, 2026

Since the notification was submitted to UODO (April 23, 2026), 18 days have passed — exactly two weeks and four days. During this time, ORIENTARIUM rebuilt the cart and modified the communication regarding partners and the method of processing payments in the informational layer of the service.

Point verification via curl conducted on May 10, 2026, at 00:37 CEST (Attachment S) confirms that the architectural core recorded on April 3 remains unchanged:

• I.3 (server software) — the server still responds with the Server: nginx/1.10.3 (Ubuntu) header;
• I.4 (CORS configuration) — preflight OPTIONS on the Orientarium tenant API endpoint (GUID f5ff01a4311c42a68af6f4d9780290d2) still returns Access-Control-Allow-Origin: * in combination with Access-Control-Allow-Credentials: true, in contradiction with the WHATWG Fetch specification;
• I.5 (DNS zone) — dig SOA homelinux.net still returns ns1.dyndns.org. hostmaster.dyndns.org. as the zone authority.

Thus, the modifications introduced after April 23 are limited to the user interface layer and informational communication. The four cardinal sins indicated in the lead — DynDNS infrastructure, EOL server software, incorrect CORS configuration, and passing personal data in URL parameters to the payment operator — remain in force on the day of publication.

A full analysis of payloads after the cart rebuild, with particular emphasis on whether the passing of CustomerEmail in the query string of the redirect to the payment gateway (Section I.2) has been retained, is the subject of a separate follow-up.

The material is an extended version of the notification submitted to the President of UODO in the system signaling mode — independent of the correspondence conducted in a separate case of the digital ecosystem of the City of Łódź (reference DKN.5101.148.2026).

Reporting irregularities in the BIP service of a municipal company

After discovering so many potential irregularities, I wanted to use the link in the footer on the Orientarium page with the serious name REPORTING IRREGULARITIES. After clicking, we are redirected to the Public Information Bulletin page, unfortunately to a 404 error page, meaning the page does not exist. Curtain.