Kintsugi Kode Case Study 02

A strong legacy store had hidden security, access and catalog debt.

The catalog was commercially strong: detailed product pages, images, filters, FAQ blocks and SEO text. The problem was not that the store was weak. The problem was that years of maintenance had left risky files, exposed package artifacts, shared admin access and messy catalog dictionaries underneath.

Anonymized case study. No domain, geography, hosting account, credentials, product niche or exact server path is disclosed.

The situation

The store was not abandoned. It had a real catalog, structured product content, rich product galleries, working category pages and mature e-commerce logic. It was exactly the kind of legacy system owners hesitate to touch: too valuable to ignore, too fragile to change blindly.

The owner wanted a practical audit, not a theoretical code review. The question was simple: what is hidden inside this working system, what should be fixed immediately, and what should go into a staged modernization plan?

The audit started with public discovery, then CMS/admin review, then server-side checks. Production changes were only made after review and approval.

What made this system risky

  • The system was built on a legacy CMS and e-commerce stack.
  • The web runtime and command-line runtime were different legacy PHP branches.
  • Product data was spread across CMS fields, e-commerce properties, product options and templates.
  • The base template had become a control room for SEO, schema, analytics, menus, footer, cart behavior and inline JavaScript.
  • Old admin practices and public artifacts created unnecessary security exposure.

What we found

The most useful findings were not visible from the outside. The storefront looked normal. The risk lived in forgotten utility files, public package artifacts, overbroad access and years of catalog/template drift.

Critical
Public administrator password-reset logic.
A legacy utility script capable of changing a CMS administrator password was still present in the public web root. It contained sensitive values and admin-level logic. This was the highest-priority issue.
High
Public CMS source archives.
Old CMS ZIP archives were downloadable from a public assets directory. They were not needed for the live site and exposed unnecessary platform/version information.
High
Public package artifacts.
Dozens of CMS transport/package archives were reachable by direct URL. These files revealed installed component history and versions.
High
Runtime mismatch.
The web runtime used one end-of-life PHP branch, while command-line scripts defaulted to an even older one. This is a classic source of silent cron/import/export bugs.
Medium
Administrator access debt.
Generic administrator accounts and broad Super User group membership made access harder to reason about and increased the impact of credential exposure.
Medium
Template debt.
The base layout template mixed structured data, OpenGraph tags, analytics snippets, desktop/mobile menus, cart behavior, footer markup and inline scripts in one place.
Medium
Catalog dictionary debt.
Product colors, dimensions and compatibility values were managed through multiple CMS/e-commerce layers. Some values needed normalization to reduce filter noise and manual errors.
Strength
Commercial content was strong.
Product pages were rich: images, descriptions, specifications, compatibility information and SEO content existed. The audit did not recommend starting over. It recommended protecting and cleaning up what already worked.

What we closed during the audit

After review, the highest-risk items were addressed as focused quick wins. The goal was not to refactor the whole system. The goal was to reduce unnecessary exposure without breaking the business.

  • The public administrator password-reset script was removed from web access.
  • The affected administrator credential was rotated.
  • Public CMS source archives were moved out of the public assets path.
  • 89 CMS package archives were moved out of direct web access while preserving a rollback manifest.
  • Temporary rewrite experiments were removed after confirming they did not solve the issue on that hosting layer.
  • Generic administrator accounts were disabled after a named personal administrator account was created and verified.

What was verified after the fixes

  • The storefront still returned a healthy response.
  • The CMS manager still returned a healthy response.
  • The removed password-reset utility no longer resolved publicly.
  • The public CMS ZIP archives no longer resolved publicly.
  • A sample package archive was blocked from direct download.
  • Automatic hosting backups were confirmed as available, with restore testing recommended as the next maturity step.

The modernization roadmap

The remaining work was split into sensible phases. That is the main difference between an audit and random cleanup: the owner knows what to do next and what not to touch directly on production.

01

Backups and restore testing

Backups existed. The next step is documenting retention and testing restore into a safe environment so the owner knows recovery actually works.

02

Runtime upgrade through staging

End-of-life PHP and older database assumptions should be upgraded through staging, not directly on the live store.

03

Template separation

Move analytics, schema, menus, footer and custom JavaScript into documented chunks and versioned assets.

04

Analytics cleanup

Confirm the active tracking setup, remove stale identifiers and document e-commerce conversion events.

05

Catalog dictionaries

Normalize colors, dimensions, brand names and compatibility values so filters become cleaner and easier to maintain.

06

Access policy

Use named accounts for owners and developers. Avoid shared administrator logins and broad legacy group membership.

Why this case matters

This was not a dramatic “everything is broken” audit. It was more realistic and more common: a store with strong content and real business value had accumulated small, dangerous leftovers over time.

That is exactly where legacy systems become risky. The business depends on them, but nobody has a clean map of files, users, templates, integrations, packages and data conventions.

The business result

  • Security exposure was reduced immediately.
  • The owner gained a clearer view of the system.
  • Developer access policy became cleaner.
  • The store and manager remained functional.
  • The next work became a roadmap, not guesswork.
Case navigation

Read the previous case: a working store with hidden operational risk.

The first case shows a different pattern: unsupported runtime, exposed internal artifacts, broken scheduled automation and a practical order of operations.

Previous case

Your legacy system may look fine from the outside.

Kintsugi Kode helps you find what is hidden inside: risky files, exposed artifacts, outdated runtimes, fragile templates, unclear access and undocumented dependencies.

Request a legacy audit