Limitless Real Estate · VPS Audit

Overview

Critical Report v9.5 · 25 Jul 2026
AB
Andy BarkerAutomate AI

The server is in a critical security state Act now

Anyone on the internet can log into the master account with a password. Every app runs with full master privileges. Sensitive business and personal files have been downloadable over the web, and some of that data has already been retrieved by outside parties. Treat this as an active security and privacy incident.

Critical findings
10
High findings
19
Source-code data taken by outsiders
71.9MB
Outside sources that pulled data
48
Longest possible exposure window
~107days

How the 38 findings break down

38findings
Critical · fix now10
High · fix this round19
Medium · plan and schedule8
Informational · clarify1

The five things that matter most

1
LIM-017 / 024 · Critical · Confirmed exposure

Customer and recruitment data was publicly downloadable

The 36MB CV archive (251 CVs), the CRM customer database, leads and user files could be downloaded over the live website with no login. Treat it as an active incident.

2
LIM-021 / 028 · Critical · Confirmed breach

Outside parties already took source code, secrets and agent files

Logs confirm 518 successful downloads of the code repository (71.9MB) by 48 sources, plus a 15-second automated run on 12 July that pulled the secrets file, source code, and the AI agent's instruction files.

3
LIM-001 / 002 · Critical

The master (root) login is open to the whole internet with a password

Anyone who guesses the password gets total control. Bots try every few seconds: over 56,000 connection attempts recorded.

4
LIM-027 · Critical

An unidentified address logged in as master 2,469 times

One outside address has been making live changes as root. It may be Lawrence's own automation, but that isn't confirmed. Confirming it is urgent.

5
LIM-020 · High · Privacy

This is likely a notifiable privacy breach

Personal information was exposed and some was confirmed taken. Under the Privacy Act this probably has to be reported to the Privacy Commissioner and affected people. The organisation needs to make that call promptly.

What's running on this server

One small DigitalOcean server (1GB RAM, Ubuntu) runs six applications behind a single web server, all under one master account.

Main Limitless app KPI server, scraping, PDF and report generation122 restarts / 2d
CRM 1,679 contacts, 1,037 call logs, 11 users80 restarts / 3d
CMA analyser property analysis and reports16 restarts
Vendor report vendor-facing document generation37 restarts
Suburb scraper address and suburb data collection36 restarts
Dashboard internal dashboard and AI features2 restarts

Three public domains point (or have pointed) at this one box: go.limitlesslinks.co.nz, lawrencekenyonslade.co.nz and scripturecoin.com. A problem in any one app can reach all the others, plus every customer database and credential.

What has actually left the building

A file that could be downloaded is not the same as a file that was downloaded by an outsider. The left column is what the server logs confirm outsiders retrieved. The right column was exposed, with no proof of outside retrieval in the logs we hold.

Confirmed taken by outsiders

Breached
Source-code repository (Git)518 successful downloads · 48 different sources71.9 MB
Production secrets file (.env)136 successful responses to 46 sourcesResend key out
Secrets backup (.env.bak)served to 4 external sources, 13–15 Jul6 downloads
AI agent instruction filesAGENTS · BOOTSTRAP · IDENTITY · SAFETY_POLICY12 Jul
Personal-data file (contacts)names, emails, phones, free text · ~124 records29.8 KB
Source and config filespart of the 48-file automated grab on 12 Jul30 files

Exposed, no proof taken yet

Exposed
CV archive (seek-cvs.zip)251 candidate CVs (PDF), unencrypted36.1 MB
CRM database backup (crm.db)405 contacts, 48 call logs in the backup184 KB
Job-application archive48 application PDFs2.8 MB
Report and export routesCMA, vendor-report and suburb-scraper outputs115 files
Additional CRM copies2 more databases under the web rootworld-readable
Retained web logs only reach back to 10 July, but exposure was possible from 10 April. "No proof taken" is limited to the logs we hold. It does not prove these were never accessed.

How the exposure unfolded

10 April 2026

Exposure window opens

A "Scripture Coin" web-server config starts serving the main app folder, which already held the code repository and lead data. This is the earliest date data could have been public.

10 July 2026 · 00:52 UTC

First confirmed outside download

Web logging begins, and 51 minutes later an outside party successfully pulls /.git/config. 220 successful Git downloads occur this day.

12 July 2026 · 07:34 UTC

The 15-second automated grab

One automated client makes 145 requests in 15 seconds and successfully takes 48 files (1.27MB): the secrets file, 11 Git items, 30 source and config files, the four AI-agent documents, and a 124-record personal-data file.

13–15 July 2026

Secrets backup harvested

The .env.bak file is served to four external sources. The Resend email credential is treated as disclosed.

17 July 2026 · ~07:13 UTC

Partial patch applied

Someone adds a block so /.env returns "forbidden" over HTTPS. Git data, archives and databases stay open, and the fix went straight into production with no record.

Through 23–24 July 2026

Retrieval continues

Successful downloads of sensitive paths keep appearing in the logs right up to the assessment. In aggregate: 518 Git downloads to 48 sources.

24–25 July 2026

This assessment

Discovery and reporting completed. Nothing on the server was changed, so remediation is not yet authorised or done.

The scale of personal data at risk

Distinct email addresses in exposed data
444
Distinct phone numbers
784
CVs in the exposed archive
251
Contacts in the live CRM
1,679

These are identifier counts, not a unique-person total, since the same person can appear more than once. A precise affected-person count is one of the open items in "What We Couldn't Test".

All 38 findings

Filter by severity or search, then click any finding to open it. Each has a plain-English explanation with the technical detail underneath.

Remediation plan and statement of work

The core hardening work is one fixed price of $2,500 plus GST, delivered as phases you can approve in priority order. An optional privacy add-on provides a breach summary email and a notification-ready document for the client to use as they see fit. The application code and deployment discovery is a separate fixed-price step at $1,500. Application code changes come later again, after that discovery.

Core hardening · in the $2,500 fixed price Optional add-on · fixed price Separate step · fixed price
Progress through the plan0 / 0 steps

Excluded from this statement of work

Handled as a later phase, priced after the discovery add-on (A2).

  • Application code remediation: authentication, uploads, download routes, CRM token lifecycle, the dashboard fallback password and the catch-all file handler
  • Dependency vulnerability upgrades and the testing that follows them
  • Implementing the move of each app to its own service account (the actual decoupling from root)
  • Full forensic disk or memory acquisition, or a rebuild from known-good source, if incident response is triggered
  • Legal advice and any Privacy Commissioner filing

Fixed prices assume the scope described here. Tick steps to track progress; the tally is per browser session and resets on reload. This summary is indicative and becomes contractual only in the signed statement of work.

What we couldn't test, and why it matters

This review was strictly look, don't touch, and worked only from the server itself. Several important questions need extra access (the DigitalOcean account, Lawrence's own devices) or a business decision. These are the known blind spots.

Questions that need answers from you

Caveats on the evidence

The logs confirm data was served to outside requesters. They don't prove what was then done with it, or the identity of the person behind an address.

"Not found in the logs" is not proof something never happened. Logs only reach back to 10 July, cover one server, and record no hostname.

No passwords, keys, tokens or customer records were copied into any report. Only counts, sizes and structure were recorded.

If any unidentified root login turns out to be unauthorised, this moves from routine hardening to incident response: credential rotation from a clean device, and possibly rebuilding the server from known-good source.