Case Studies Code Review

Case Study: Ironbark Urban Products Security Review

Author
Dulanjana Fernando
Aug 29, 2026  •  17 min read  •  369 views
Case Study: Ironbark Urban Products Security Review

Ironbark Urban Products is the pseudonym used for a small-to-medium-sized Australian business operating in the manufacturing and supply sector. The security review uncovered several dangerous weaknesses that had accumulated over time. The system looked healthy from the outside, while security risks had accumulated underneath.

1. The Client

For confidentiality, I will refer to the organisation as Ironbark Urban Products. Ironbark is a small-to-medium-sized Australian business operating in the manufacturing and supply industry.

Like most of the other small-to-medium businesses, they do not have a dedicated cybersecurity team or a separate employee to manage all IT-related matters. The company CEO was handed all the IT-related responsibilities along with his own day-to-day responsibilities.

IT-related responsibilities included website management, hosting and email management, domain and DNS management, along with all other general IT-related decision-making responsibilities.

The business had not deliberately neglected cybersecurity. The website was working, emails continued working, no obvious signs that there was a security-related issue underneath.

2. Why the Review Was Performed

The review was performed as a review of the existing legacy environment, and the objective was to understand how the environment had evolved in the hands of the overseas freelance developers that the company hired over the years to develop different functionalities and fixes.

The review combined external inspection with configuration analysis and source code review.

Source code review was important because the most significant findings would not have been obvious from simply browsing the website.

3. Scope

The review covered a significant area of Ironbark Urban Product's digital environment, such as:

  • Public-facing website
  • Server configuration
  • DNS records

The goal was to identify security weaknesses that could expose the system to compromise or increase the impact of another vulnerability.

4. What I Found

The assessment found multiple security issues across the infrastructure and application layers.

# assessment findings
Finding                                                        Severity
---------------------------------------------------------------------------------------
Anonymous FTP access to the web root                           Critical
Legacy PHPMailer 1.73 still actively used                      Critical
Confirmed path traversal in image-processing component         High
.php7 and .phtml configured as executable PHP                  Medium
PHP 7.4-based runtime                                          Medium
Stale and duplicated DNS/email records                         Low / Configuration
Software version disclosure through email headers              Low

The important finding was the way multiple weaknesses had accumulated across the environment, most probably due to the lack of context and functionality-delivery-focused software development by the freelance developers who worked on the system over the years.

4.1 Anonymous FTP Access to the Web Root

One of the infrastructure misconfigurations identified by the assessment was that Anonymous FTP access was enabled to the website root directory.

Article Image
Anonymous FTP Access to the Web Root

The anonymous user account was granted read and write access to the web root directory. Public-facing web servers should not have unnecessary file transfer services enabled.

This was a misconfiguration with a critical severity.

4.2 PHPMailer 1.73 Was Still Actively Used

One of the most important discoveries came from something as simple as a confirmation email. Inspecting the raw source of the email disclosed the version number and the mail library used by the application.

# email raw source content disclsed the version and library used
X-Priority: 3
X-Mailer: PHPMailer [version 1.73]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="iso-8859-1"

This decades-old PHPMailer version was used to send a confirmation email when the website's contact form was submitted. The production website was still using this legacy library.

This finding was important because PHPMailer 1.73 has known Remote Code Injection(RCE) vulnerabilities, including CVE-2007-3215 and CVE-2016-10033.

Continuing to use this older version with known vulnerabilities creates a critical-severity risk as well as a significant dependency risk.

4.3 Confirmed Path Traversal in a Custom Image Component

A significant application-level vulnerability was found inside a customised image-resizing script.
The application contained a rewrite rule similar to /image-catalog/{directory}/{image} which internally passed user-controlled values into an image processing script. The script accepted the directory value directly from the request $dir = $_GET['dir']; and constructed the filesystem path using a function.

The function simply concatenated the supplied value into the media directory. return APPLICATION_ROOT . "/" . MEDIA_DIRECTORY . "/" . $subPath

This meant that an attacker could use this image resize script for a path traversal.

However, the interesting part of this finding was that the security validations for the image resizer script were available but commented out. I couldn't know why it was commented out in the codebase, and the company also did not have any idea that it was commented out in the first place.

4.5 Executable .php7 and .phtml Files

Apache configuration contained AddHandler application/x-httpd-alt-php74___lsphp .php .php7 .phtml. This meant that Apache would treat .php7 and .phtml extensions as executable files too.

Even though this configuration is not a vulnerability itself, it significantly increases the impact of a weak file upload. As an example, an attacker can generate a malicious file that contains an image signature while also containing PHP code. Then the uploaded file may pass image validation while still being interpreted as PHP by Apache.

This seemingly minor server configuration can increase the impact when combined with the path traversal vulnerability can significantly increase the impact.

4.6 Legacy PHP 7.4 Runtime

The production server was using a PHP 7.4-based runtime, and PHP 7.4 reached end-of-life in November 2022. This means it no longer receives standard security support.

Relying on an ageing runtime creates unnecessary risks. Older runtimes also make application modernisation much more difficult because developers are often forced to use older library versions, legacy frameworks and deprecated syntax.

This creates a cycle where one outdated component makes it harder to remove another.

4.7 DNS and Email Configuration Drift

The review also found old and duplicated DNS-related records.
These included unused SendGrid-related records, duplicated mail records and multiple historical email provider records.

This is not necessarily a vulnerability, but it indicates how the infrastructure changes had accumulated over time and were forgotten because it was not anyone's responsibility.
Configuration hygiene matters because sometimes it can create verification problems and increase the attack surface, and more importantly, complexity itself eventually becomes a security risk.

4.8 Software Version Disclosure Through Email Headers

The PHPMailer issue exposed a significant information disclosure weakness. The website disclosed the library name and version that was used to send emails directly in the email headers.
An attacker did not need to use any tools or trigger error messages to get the website to disclose information; just using the contact form in the intended way was enough.

Even though the version disclosure is not a serious vulnerability by itself, it reduces the work required for an attacker to identify vulnerabilities in the program.

Once the service name and exact version are known, vulnerability research becomes substantially easier.

5. Why It Mattered

Security findings become meaningful when the security impact is translated into business impact.

  • Anonymous FTP with write access can directly change the application functionality.
  • The path traversal vulnerability could expose files that are not accessible through the public website.
  • The outdated PHPMailer library contained vulnerable code that could allow remote execution of arbitrary code on the server.
  • Executable .phtml and .php7 extensions increased the consequences of weak upload validation.

Under the wrong combination of conditions, these vulnerabilities could lead to website compromise, malware installation, credential theft, customer data exposure, website defacement, and reputational damage.

For a small-to-medium-sized business, several days of disruption can have a meaningful operational and financial impact.

6. How the Risk Developed

The most important part of this case study is understanding how an application reaches this point. No one intentionally uses a vulnerable system for a business.

The risks have accumulated gradually. Developers changed, custom code was modified, email providers changed, redirects were added, new components were added, but from the business perspective, the application worked as intended.

At the same time, IT responsibilities were being handled by the already busy CEO alongside the normal responsibilities of running the company. Technology management had to compete with customers, employees, projects and deadlines, sales, suppliers, meetings, and day-to-day management decisions.

That is how technical debt becomes security debt.

And it is not unique to Ironbark Urban Products.
Many small and medium-sized organisations operate systems that were built years ago, modified repeatedly and never comprehensively reviewed.

7. Recommended Remediation

For Ironbark Urban Products, the recommendations could be divided into immediate, short-term and long-term priorities.

7.1 Immediate

  • Anonymous FTP access should be removed immediately. If there is a special business requirement for FTP services, a dedicated user should be created and identified by a username and a strong password.
  • Remove the legacy PHPMailer 1.73 library and upgrade to a supported version or migrate to another supported library.
  • The image-processing code should no longer accept filesystem directory values directly from user input. Requested resources should be resolved only against approved directories.
  • All upload handlers should be reviewed to ensure files cannot retain executable extensions.
  • Credentials that can potentially be exposed should be rotated.

7.2 Short Term

  • Upgrade PHP
  • Upgrade other legacy libraries
  • Harden Apache configuration
  • Clean up DNS records
  • Review all file-upload handlers

7.3 Long Term

Security should be an ongoing process rather than another one-off process.

  • Maintain a dependency inventory and monitor continuously against vulnerabilities
  • Remove unsupported software
  • Implement centralised logging
  • Document responsibility for application security
  • Review hosting configuration after major application changes
  • Perform regular external security reviews

A small business does not necessarily need a large internal security team. But someone needs to be responsible for asking these questions periodically.

8. Outcome

The assessment gave Ironbark Urban Products a clearer understanding of risks that had remained largely invisible during normal business operations.

The highest-risk issues were identified and prioritised.

9. Lessons for Other Businesses

A business website or an application can load correctly, send emails, generate reports, generate leads and support everyday operations while still containing serious security weaknesses underneath. Outdated systems rarely announce themselves.
From a business perspective, everything will appear normal.

If your business operates an application that has evolved over many years, the environment may benefit from a security review.

10. When Was Your Environment Last Reviewed?

Vulnerabilities like these often remain unnoticed because the systems continue to work normally. A website can look perfectly healthy while outdated dependencies, insecure configurations and application vulnerabilities remain underneath.

You do not need a large internal security team to start improving your security posture. Sometimes the first step is simply understanding what is already there.


If your business relies on a website, custom application or cloud infrastructure and it has not undergone a security review recently, I can assess the environment and provide a prioritised remediation report.

Until a dedicated Security Review page is available, enquiries can be submitted through the standard contact form.

Tags:
Code Review

You might also like...

Case Study: BrightByte Technologies Security Review
Case Studies Code Review
Case Study: BrightByte Technologies Security Review

BrightByte Technologies is the pseudonym used for a small-to-medium-sized Austra...

Read More

Stay Updated

Get notified when new walkthroughs and security articles are published.