I've talked with Opus4.6 about this:
Oh no.Look at what the footer actually says:
Those theme names are version indicators. This is almost certainly IP.Board 3.x from circa 2015 — over a decade old. The current version of Invision Community is 5.x. They are multiple major versions behind.
Change Theme · IP.Board · 2015b · IP.Board Mobile · 2015a
This is exactly the worst-case scenario I described earlier but now we have confirmation.
What we're looking at:
- IP.Board 3.x, frozen circa 2015 — this version stopped receiving security patches years ago. Invision Power Services dropped support for IPB 3.x long before they even dropped IPB 4.x. There is no path to getting security updates for this software short of a full migration.
- Hosted by canaca.com since 2002 — Canaca is a small Canadian hosting provider. Not inherently bad, but "small Canadian host running a 2015-era PHP application" is not the same as "managed hosting with proactive security monitoring."
- Licensed to ImmInst.org — that's the Immortality Institute, LongeCity's original name. The license itself may be expired, which would mean they can't upgrade even if they wanted to without buying a new license (IPS has changed their licensing model several times since 2015).
- Global Forum Sponsor 2015/16: crackaging.com — the fact that the sponsor line in the footer is from 2015/16 and hasn't been updated in a decade tells you everything about how actively this installation is being maintained.
- CodingJungle listed as an advertiser — CodingJungle made IPB plugins. Many of which are also abandoned.
How bad is this specifically:
IP.Board 3.x has had multiple disclosed vulnerabilities since it stopped being maintained. Without doing a proper vuln scan (which I obviously shouldn't against a site I don't own), the classes of vulnerability that affect old IPB 3.x installations include:
- SQL injection in search functionality
- Stored XSS in various input fields
- Authentication bypass in certain configurations
- Remote code execution via file upload handling
- CSRF in admin panel operations
- PHP object injection via unserialize() calls
The PHP version it's running on is almost certainly EOL. IPB 3.x requires PHP 5.x or early 7.x. Whatever version canaca.com has it on is probably not getting PHP security patches either.
The data at stake, being specific:
LongeCity has been running since 2002. That's 24 years of:
- User emails and password hashes (IPB 3.x uses md5 with salt — fast to crack)
- Private messages spanning two decades of longevity community discussions
- Detailed personal health protocols, supplement stacks, drug combinations
- Blood test results with values
- Discussions of purchasing prescription drugs without prescriptions
- Nootropic experimentation reports including controlled substances
- Real names for many users (the community was more trusting about identity in the 2000s)
- IP addresses correlated with all of the above
For a community dedicated to life extension, the threat model includes insurers or employers accessing this data to discriminate against people who are self-medicating with experimental drugs. That's not paranoid — it's a realistic consequence if this database is exfiltrated and linked to real identities.
The honest assessment: this may already be compromised.
I want to be clear about my uncertainty here — I have no evidence that LongeCity has been breached. But the base rate for unpatched decade-old forum installations with known CVEs being compromised is very high. Automated scanners hit these continuously. The question isn't really "can it be compromised" — it's "has anyone bothered to, and did anyone notice if they did?"
A breach of LongeCity might not be visible. The most common exploitation of old forums is silent database exfiltration — copy the user table, crack the hashes, add the credentials to combo lists. No defacement, no visible damage. The forum keeps running. The users never know. Their email/password combinations get sold on dark web markets and used for credential stuffing against other services.
What should happen, in brutal priority order:
Immediately (this week):
- Someone with admin access needs to take a full database backup and store it offline, encrypted. If the server gets compromised or the hosting goes down, the content is gone forever without this.
- Change the admin password to something unique and long. If the admin account is compromised, everything else is moot.
- Put Cloudflare in front of it. Free tier is fine. This at minimum provides a WAF layer that blocks the most common automated attacks against old PHP applications. This is a 30-minute DNS change and it meaningfully reduces the attack surface.
Short term (this month):
- Begin a static HTML archive of all public content. Tools like HTTrack or wget can mirror the public-facing pages. This preserves the knowledge even if the forum goes down. This is the single most important preservation action.
- Seriously evaluate whether DMs should be purged. Two decades of private messages sitting in an insecure database is a liability, not an asset. If the content isn't actively needed, deleting it removes the most sensitive data from the attack surface. This is a hard conversation for the community but it's the right one.
- Audit what the database user's MySQL privileges are. If the forum's MySQL connection has excessive permissions (FILE, GRANT, PROCESS, etc.), restrict it to the minimum needed. This limits what an attacker can do even if they achieve SQLi.
Medium term (next few months):
- Migrate to Discourse. This is the real answer. rapamycin.news already did it and it's the right platform for this kind of community. Discourse has import tools for IPB. The migration is work but it's a solved problem. The alternative — staying on decade-old unsupported software indefinitely — is not a viable long-term plan.
- If migration is impossible (no budget, no technical capacity, no admin availability), at minimum convert to a read-only static archive. Disable registration, disable posting, disable login, serve the content as flat HTML. This eliminates essentially all attack surface while preserving the knowledge base.
The human problem:
LongeCity is a nonprofit run by volunteers. The people who run it are passionate about longevity, not sysadmin. The license is from ImmInst.org, the original organization. The sponsor line hasn't been updated in a decade. This all points to: the technical maintenance has been on autopilot for years, and the people who could authorize and execute a migration may not be reachable, available, or technically able.
This is the same pattern as every dying forum we've discussed. The content is irreplaceable. The infrastructure is decaying. The people who could fix it have moved on or don't have the resources. And the threat environment is getting worse.
If you have any connection to LongeCity's current administrators, this is a conversation worth having now, not after a breach makes it urgent. The Cloudflare step alone — free, 30 minutes — meaningfully improves the situation. The static archive — a day of work — ensures the knowledge survives regardless. And the Discourse migration — a real project but achievable — solves the problem permanently.
The longevity community is, somewhat ironically, facing the question of whether their own community's institutional memory will outlive its infrastructure.
Edited by InquilineKea, Today, 09:36 PM.
