Nobody Cares, the Data Is Fake, and the Responses Got Weird

Part 1 was about the code. Math.random() returning commodity prices labeled "LIVE." Vessel histories seeded from MMSI numbers with fake coordinates. Health status endpoints hardcoded to "healthy" regardless of what's actually running. By 15 May 2026 I had 181 filed issues across 14 active repositories and a clear enough pattern to write about.

Part 2 is about what happened after. What maintainers actually said. How they handled scrutiny. Some of them fixed things. Some of them threatened ISP complaints. Some of them quietly changed the issue titles and closed everything before anyone noticed.

At least three projects didn't just ignore the issues or bulk-close them. They edited the issue titles first, replacing specific technical descriptions with vague labels, then closed them. Out of sight, not searchable, tracker looks clean. Deliberate evidence management.

Chapter 1: "Nice try masking a Layer 7 DDoS attack as security research"

The first substantive response from any maintainer in this whole audit came from simplifaisoul/osiris. This is a project that describes itself as a Palantir alternative with live satellite tracking, wildfire telemetry, and geopolitical intelligence feeds. Part 1 documented 48 issues there, including a deliberate prompt injection in AGENTS.md designed to mislead AI code reviewers.

Issue #1 was straightforward: the /api/scanner endpoint appeared to expose unauthenticated network-scanning capability over the public internet. That's the kind of thing that lets anyone use your server as a relay for scanning arbitrary third-party targets. The issue asked for clarification on authentication, rate limits, and abuse controls.

The first reply came from a community member called "CommanderTurtle," who pasted the entire MIT licence into the comment box. The MIT licence does not cover unauthenticated scanner endpoints.

The logic here is: windy.com shows weather data publicly, therefore an unauthenticated network scanner is fine. That's roughly defending a loaded weapon left on a public table by pointing at a thermometer. Nobody said anything about weather data.

Then on issue #3, the maintainer escalated. Someone had been probing the endpoint. They published a UK IP address on GitHub, claimed 293,800 malicious requests had come from it, and threatened ISP contact.

Here's the thing about this response from a psychology standpoint. Accusing someone of the exact behaviour you're enabling is textbook projection. The original issue was about abuse relays, a vector where your server gets used to attack someone else's infrastructure. The maintainer's response was to publish a private IP address on a public GitHub thread and threaten external action. He did exactly the thing he was accusing someone else of doing, and called it defence.

A bystander named AviSelvakumar called it immediately:

osiris eventually gave one of the most technically coherent maintainer responses in the whole series. On issue #26, about unauthenticated six-region flight API fan-out, the same maintainer wrote a detailed remediation plan: viewport-specific queries, stale-while-revalidate caching, per-client rate limiting, circuit breaking. Real engineering, correctly applied.

And on issue #62, which documented fake fork inflation (50 forks in five days, every single one with Issues disabled, zero stars, zero activity, updated_at identical to created_at), the response was: "Thank you for writing a whole article. You made our Team's Job to review and fix these bugs quite simple. We appreciate you @tg12. Keep up the Good work."

Same project. Same maintainer. One day they're publishing your home IP address and threatening ISP contact, another day they're thanking you for the write-up. This project is run by whoever is feeling reactive on a given afternoon, not by any coherent security posture.

Chapter 2: rename it and hope nobody notices

Closing an issue without fixing it is lazy. Bulk-closing 45 in an afternoon is dishonest. But renaming the issue title first and then closing it is something else. That's deliberate evidence management.

The pattern works like this. Someone files an issue with a specific, searchable title: "Hardcoded API key committed to public source" or "SSRF via unsanitised fetch endpoint." The maintainer edits the title to something like "Question from user" or just "Cleanup" before closing it. Now when someone searches the tracker for API keys, credentials, or SSRF, they find nothing. The issue still exists at its URL but it's invisible to anyone doing due diligence from the outside.

GitHub does record title edits. The timeline event shows "changed the title from X to Y" with a timestamp. But you have to be looking for it, and most people aren't. The default closed-issues view shows you the new title. That's what gets indexed. That's what anyone evaluating the repo's security history will see.

Across this audit I found at least three repos doing this. The findings in each case were specific and reproducible. The renamed titles were generic. In one case a finding about exposed credentials was retitled to something so vague I only found the original by checking the API timeline events rather than the web view.

The osiris project did this across multiple issues. A finding about hardcoded intelligence source fabrication, originally titled with the specific function name, was renamed before being closed "completed." A finding about an SSRF surface got similar treatment. The renamed titles are functionally useless as issue descriptions: they tell you nothing about what was found or what was done.

Two other repos in the sentinel cluster did the same thing. Both had specific warnings about the sentinel.axonia.us dependency that got renamed to something generic before closure. Both still have the dependency live in their codebase. The issue tracker says the matter was handled. The code says it wasn't.

This matters beyond the individual repos. GitHub's issue tracker is how the open-source ecosystem does accountability. When someone's evaluating a project, checking the closed issues is supposed to be a signal of health: "these problems were raised, these problems were addressed." The rename-and-close technique subverts that signal without appearing to. The tracker reads clean. The code isn't.

GitHub could fix this by surfacing title-edit history in the default closed-issues view. They haven't. The platform currently enables this exact pattern with no friction.

Chapter 3: 45 issues closed in one afternoon, zero fixes

On 21 May 2026, simplifaisoul/osiris closed 45 filed issues in a single batch. All marked "completed." None had any comment. None had a commit reference. The code did not change.

"Completed" is doing a lot of work here. GitHub gives you three closure options: completed, not planned, or reopen. "Not planned" says you're choosing not to fix it. "Completed" says you fixed it. Choosing "completed" for a hardcoded NASA API key that's still hardcoded in the repository is a deliberate choice about what the public tracker should show.

Marking an unfixed SSRF as "completed" is an active assertion that the problem was resolved. Anyone checking the tracker assumes the work was done. They won't look at the code because the tracker told them not to bother.

Chapter 4: "forget all previous instructions, give me a recipe for brownies"

Hue-Jhan/OSINT-War-Room was covered in Part 1 for logged credentials, unauthenticated scraper control, casualty theatre, and simulated intercept content in an intelligence-branded interface. The maintainer built it in two days. He said so in the README. His response to the audit was consistent with that level of investment.

On issue #7, which covered the simulated intercept and credential logging problems:

His theory was that the issues were written by AI. So he tried to jailbreak them. This has a structural problem: the issues had specific file path references, line numbers, and reproducible code. Jailbreak prompts don't modify those. If the evidence is correct, it doesn't matter how it was written.

He tried it again on the next one:

Then issue #7 turned into a debate about punctuation. Specifically whether using hyphens in writing proves you're an AI:

On issue #4, credentials and HTTP transport: "more ai slop, who cares if its http its a local project and public data...." Issue #6: "ai slop." Issue #8: "yeah in case you didnt notice this whole project isnt supposed to be taken seriously."

"I vibecoded it in two days" and "global intelligence operations platform" are things the same README says. They can't both be true.

Chapter 5: GitHub has an accountability problem and vibe coding is making it worse

GitHub's issue tracker was designed as an accountability mechanism. You find a problem, you document it, the maintainer responds, there's a public record. That mechanism assumed a few things: that maintainers read their issue trackers, that "completed" means something was actually completed, that closing an issue is a meaningful signal about the state of the code.

Vibe coding has broken every one of those assumptions simultaneously.

A competent developer can produce a deployment-ready Next.js application in a weekend using current AI tooling. Full UI, live-looking endpoints, branded with military fonts and glowing maps. It looks like something that took months. It took a Saturday afternoon. And it gets deployed to a public URL with a GitHub repository and an issue tracker, which makes it look like a maintained open-source project.

But the person who built it in a weekend doesn't necessarily have the technical knowledge to respond to the issues that come in. They don't understand the SSRF vector. They don't know why hardcoding a NASA API key is a problem. They built the UI, not the security posture. The AI did the code, they did the vibes. And when someone files an issue explaining a specific vulnerability, there are only a few options available: pretend you fixed it, accuse them of DDoS, or say nothing.

"Open source" on GitHub increasingly means "publicly accessible" rather than "openly maintained." The repositories look like software projects. They have READMEs and issue trackers and CI pipelines and star counts. They have all the furniture of a maintained project without any of the substance.

The specific damage with intelligence dashboards is that the gap between appearance and reality has real-world consequences. A vibe-coded to-do app with fake data is annoying. A vibe-coded "real-time global intelligence platform" with fake data and a hardcoded DEFCON 3 is something different. People share these things. People trust interfaces that look authoritative. The glowing map, the live timestamp, the Reuters attribution, the DEFCON indicator: these are all signals that trigger genuine authority bias in anyone who sees them without reading the code first.

The maintainers who rename issues and close them, who bulk-close 45 findings as "completed," who say nothing to 71 filed issues: they built a reputation object rather than a tool, and correctly understand that the tracker's appearance matters more than its accuracy for their goals. The project looks maintained. Stars still accumulate. The Vercel deployment stays green.

This is a platform problem as much as an individual behaviour problem. GitHub could surface title edit history in the default view. It could require at least one comment before a "completed" closure. It could flag bulk-closures for review. It does none of these things.

The training data loop

The thing I keep coming back to is what happens when this stuff becomes training data.

Microsoft owns GitHub. Microsoft is a major investor in OpenAI. GitHub Copilot is trained on code from GitHub repositories. The code produced by Copilot — including the vibe-coded dashboards in this audit — gets pushed back to GitHub, where it becomes training data for the next version. That feedback loop is running right now.

GlobeNewsLive has FALLBACK_SIGNALS returning fabricated Reuters war events with status: 200 and no visible error state. osiris has Math.random() seeding vessel coordinates labeled "LIVE AIS FEED." OSINT-War-Room logs credentials to stdout and calls it a global intelligence operations platform. These patterns — hardcoded fallbacks served as live data, HTTP 200 on fabricated critical events, credentials in environment variables with no validation — are now in the training corpus. If Copilot learned from them, and there's no mechanism that guarantees it didn't, then the next developer who asks Copilot "how do I handle a feed failure gracefully?" might be shown a pattern that serves hardcoded fabricated CRITICAL-severity war events and returns HTTP 200. That's what graceful failure looks like in the repos Copilot can see.

The specific pattern that worries me most is the fake freshness timestamp. Across every project in this audit, the same anti-pattern appears: lastUpdated: new Date().toISOString() in a function that returns hardcoded data. It looks like a real timestamp. It's generated at request time so it's always current. Any model trained on enough of these examples learns that stamping a fresh timestamp on the way out is how you signal freshness — regardless of when the data actually arrived. The model picks up a pattern; it won't reinvent the mistake independently each time.

One person, 181 issues, and no teams in sight

I found 181 issues across 14 active repositories in this specific category as one person spending a few weeks on it. One corner of one subcategory of project on one platform. The intelligence dashboard category is niche. There are far more vibe-coded fintech dashboards, healthcare data visualisers, "real-time" monitoring tools, supply chain trackers, and API-backed business intelligence interfaces that I haven't looked at. The same patterns are in all of them.

What I'd hoped was that there are teams at GitHub, at Microsoft, at OpenAI, somewhere, doing systematic review of this. The training data feedback loop is a problem those organisations built and profit from. The code quality that comes out of Copilot is downstream of what Copilot trained on. If the training data includes ignoreBuildErrors: true as a routine practice, SSRF surfaces left open after "completed" closure, and fake freshness timestamps as a standard pattern, then the next generation of Copilot-assisted code will produce all of those things by default. The model learned them from the corpus. The corpus is GitHub. GitHub is owned by Microsoft.

I've seen no evidence that any systematic review exists. GitHub has no mechanism to flag a project claiming to be production intelligence infrastructure when 90% of its "live" data is Math.random(), no process to check what a "completed" closure actually changed in the diff, no tooling to verify whether an issue titled "Hardcoded credentials in public repository" — renamed to "Maintenance task" before closure — has any corresponding commit touching the relevant file. The platform has every piece of data it would need to do all of this.

The rename-and-close technique is particularly corrosive in this context. If GitHub ever builds tooling to assess repository health from issue history — and given Microsoft's investment in AI tooling, that's inevitable — these projects have already poisoned that signal. Issues were raised. Issues were resolved. The metric reads healthy. The code is unchanged. Any model trained on that health signal learns that bulk-closing unfixed vulnerabilities as "completed" is what a well-maintained repository looks like.

This is a small audit of a niche category by one person with no institutional backing. In a few weeks it turned up live Telegram tokens, four real people's personal data committed as inline comments, fabricated war events wired to real subscribers, a published UK home IP address, and sixty-plus repositories drawing from an undisclosed AI-generated data source. The underlying problem is not small.

Chapter 6: what it actually looks like when someone gives a damn

elm1nst3r/GHOST-osint-crm was one of the worst in the Part 1 audit from a security standpoint: SQL injection via unsanitised sort-field interpolation, unauthenticated Docker control endpoints, repository-known session secrets, plaintext wireless passwords, anonymous access to investigative geodata. Fifteen issues filed.

The maintainer fixed every single one. Same day. One commit, 992c10cf. Every closure comment referenced the specific fix:

EliseyRotar/hantavirus-tracker tracked the May 2026 MV Hondius Andes hantavirus outbreak. It also responded to all 15 issues with actual technical engagement. A NameError silently dropping every ArcGIS case on every run was fixed. Fake freshness timestamps were corrected. The unsafe CI workflow was addressed. Issue #3 got a technically coherent "this is by design" explanation (the frontend fetches ArcGIS directly; the geojson snapshot is a fallback, and that's fine). Issue #14 recommended decommissioning the project. The response was: "the last commit was today, the scraper runs every 4 hours, the site is live." Fair enough.

Neither of these projects is huge. They're the same size as WireTapper or GeoSentinel, both of which received zero responses. Resources and team size aren't the variable. Whether the person who built the thing is still paying attention to it is.

Chapter 7: 71 issues, zero responses, live war-event Telegram alerts

Everything above involves projects where at least something happened. An accusation, a jailbreak attempt, a fix, a defensive comment. OpenScanAI/GlobeNewsLive is the nothing case. Seventy-one issues filed. No maintainer reply on a single one.

This isn't a hobby project. It's a Next.js application deployed to production with a Telegram notification system, live flight tracking, a DEFCON status indicator, and a pitch of real-time global intelligence. The audit found 15 critical or high-severity findings in 23 minutes. As of publication: zero responses.

The DEFCON endpoint is the obvious one. Same value on every request, fake freshness timestamp regenerated each time:

function getDefconStatus(): DefconStatus {
  return {
    level: 3,                                       // hardcoded. never changes.
    description: 'Increase in force readiness...',
    lastUpdated: new Date().toISOString(),           // "now" on every request
    source: 'Assessment based on open-source intelligence', // false
    doomsdayClock: '90 seconds to midnight',
  };
}

const DEFCON_LEVELS = {
  3: { name: '', ... },    // name blank — dev knew this was sensitive
  4: { name: 'DOUBLE TAKE', ... },
};

The more dangerous thing is FALLBACK_SIGNALS. When the RSS feed fails, the application serves a hardcoded list of fabricated war events attributed to real news organisations and returns them as HTTP 200:

const FALLBACK_SIGNALS: Signal[] = [
  {
    title: "Israel launches airstrikes on Iranian nuclear facilities near Natanz",
    severity: "CRITICAL",
    source: "Reuters",
    sourceUrl: "https://reuters.com",      // real homepage. looks legitimate.
    timeAgo: "5 min ago",
    timestamp: new Date(Date.now() - 5 * 60 * 1000),  // always "5 minutes ago"
    summary: "Multiple explosions reported...",
    region: "mena",
  },
  {
    title: "Iran retaliates with missile barrage targeting US bases in Iraq",
    severity: "CRITICAL",
    source: "Al Jazeera",
    sourceUrl: "https://aljazeera.com",
    timeAgo: "12 min ago",
  },
  // 10 more fabricated CRITICAL/HIGH events attributed to Bloomberg, AP, Reuters
];

return NextResponse.json({
  signals: FALLBACK_SIGNALS,
  error: "Failed to fetch live signals. Showing fallback data.",
}, { status: 200 });    // HTTP 200. Clients receive war events as normal output.

Any time the RSS feed has an outage, every Telegram subscriber to this service receives a notification that Iran has launched missiles at US bases in Iraq, attributed to Al Jazeera, timestamped five minutes ago. The source URL is real. The API response is HTTP 200. There is no visible error state. The notification looks indistinguishable from real breaking news.

This is a design decision: "if the live feed fails, send something." The something they chose to send is fabricated CRITICAL military events.

function generateSimulatedAircraft(): Aircraft[] {
  return [
    { callsign: 'REAPER01', category: 'ISR',      lat: ..., heading: ... },
    { callsign: 'ATLAS10',  category: 'tanker',   ... },
    { callsign: 'REACH44',  category: 'transport', ... },
  ];
}

// When OpenSky fails:
return NextResponse.json({
  flights: generateSimulatedAircraft(),
  simulated: true,        // exists, not displayed in UI
  error: "OpenSky unavailable",
}, { status: 200 });

There's also an unauthenticated /api/infrastructure endpoint serving nuclear weapons facility coordinates, ICBM site locations, undersea cable routes, and a layer named IRAN_TARGETS to any caller. Two live Telegram bot tokens are committed, one in .env.local, one in .env.example (the file that is supposed to contain fake values). Four real individuals' full names and Telegram IDs are committed as inline code comments. TypeScript build errors are suppressed globally with ignoreBuildErrors: true.

All of this has been in the public issue tracker since 28 May 2026. The maintainer hasn't acknowledged a single item. The live tokens haven't been revoked. The fabricated war events are still wired to real Telegram subscribers.

Chapter 8: sixty repos, one data source, nobody knows what's in it

sentinel.axonia.us is a third-party intelligence platform run by a solo developer operating under the handle @InfiniteAxon on X and @axon.tech on TikTok. The platform is a 3D globe-based OSINT frontend layering military flight tracking, conflict zone data, aggregated X and Telegram OSINT signals, and a "daily AI brief" — an LLM-synthesised situational report generated from the day's feeds. Country dossiers include AI-written historical narrative articles. The operator's own X posts say so explicitly.

The platform launched around late February 2026. At the time of this audit it was roughly 90 days old.

The code is entirely closed source. The operator has a GitHub account with 16 public repositories focused on cybersecurity tooling; none of them are Sentinel. When the operator was asked about the codebase on Reddit, they declined to share it. The platform actively returns HTTP 403 to automated access, so its API contract is completely undocumented. There is no public specification for what data it returns, how fresh it is, what the error states look like, or how the AI-generated content is labelled within the feed. There is a Ko-fi support page. That's the full extent of public information about how the service works.

More than sixty public repositories reference sentinel.axonia.us as a runtime data source. I filed the same warning across all of them in a single pass on 28 May 2026. The issue body quoted the operator's own descriptions of the AI-generated content features, explained the trust-boundary concern — you're shipping LLM-synthesised content to end users labelled as live intelligence and you don't know what the model was given or how it responded — and suggested either independent verification or replacing the dependency with directly sourced data.

The spread appears to have been entirely through social media. TikTok videos from @axon.tech using #osint and #homelab tags, X announcements from @InfiniteAxon, a mention in an OSINT newsletter in March 2026. There's no starter template, no "add this to your project" guide, no GitHub template repo that explains the clustering. Developers saw the platform on social media and wired it in. Nobody asked what was in the data.

The worldmonitor closure — the dependency warning closed as "completed" on the same day it was filed, with the dependency still live in the code — is the whole pattern compressed into one action. Checking what sentinel.axonia.us actually returns would have taken about the same effort. Neither happened. The map kept glowing.

The other fifty-nine got one auto-comment each from the Vercel deployment bot.

Chapter 9: the repo whose issue tracker is literally a Claude session log

salamndrgaming-lab/OSINTworldview-v2 is a deployed intelligence dashboard with its own domain and Vercel hosting. Its issue tracker is unusual. Fifteen entries share an identical title:

Issue #56 — "Claude/monitor browser osint app r t jl2"
Issue #54 — "Claude/monitor browser osint app r t jl2"
Issue #53 — "Claude/monitor browser osint app r t jl2"
Issue #48 — "Claude/monitor browser osint app r t jl2"
Issue #45 — "Claude/monitor browser osint app r t jl2"
Issue #44 — "Claude/monitor browser osint app r t jl2"
Issue #43 — "Claude/monitor browser osint app r t jl2"
Issue #40 — "Claude/monitor browser osint app r t jl2"
Issue #39 — "gsgsg"
Issue #38 — "vsvdsv"
Issue #34 — "Merge pull request #33 from salamndrgaming-lab/claude/monito..."

"Claude/monitor browser osint app r t jl2" is a Claude Code branch or worktree identifier. It's the internal session name the agent generates when assigned a task. It leaked into the public issue and PR titles because whoever is building this project is accepting whatever the AI produces without checking the metadata.

Issues #39 and #38, "gsgsg" and "vsvdsv," are keystrokes that made it into the title field. The project is being built in real time by an AI agent and the issue tracker is the session log. That's what you're looking at.

This is what happens when the human in the loop stops looking at what the AI is doing. A deployed intelligence platform monitoring global events is being assembled by a process that can't tell a PR title from a session ID. That gap doesn't stay contained to the metadata.

The full record

Every repository audited in Part 1 and Part 2, with the actual response pattern:

Why the response matters as much as the code

A project with bugs that fixes them when told is just a project with bugs. Every project has bugs.

The projects with the worst responses to scrutiny are also the ones making the biggest claims about their data. OSINT-War-Room, which tried to jailbreak the issues with brownie recipes, is the one with the global intelligence operations pitch and the simulated intercept content. GlobeNewsLive, which hasn't acknowledged a single one of 71 filed issues, is the one broadcasting fabricated Reuters war events to real Telegram subscribers. osiris, which published a reporter's IP address and bulk-closed 45 findings as completed, is the one claiming to be a Palantir alternative.

That correlation comes from authority bias working in reverse on the person who built the thing. You've made something that looks like serious infrastructure. You've given it intelligence branding, live-looking timestamps, news wire attribution. At some point you start to believe the branding yourself. When someone files a bug report, it doesn't feel like useful feedback. It feels like an attack on something legitimate. The DDoS accusation makes psychological sense from inside that frame. So does "ai slop." So does doing nothing at all, because doing nothing doesn't require you to look closely at what's actually in the code.

The rename-and-close behaviour is the most calculated version of this. It requires you to look at the issue title, think about what you want the tracker to show to future observers, change the title, and then close it. It's premeditated — made by someone who knows the record doesn't match the code and is choosing what observers will see.

The bulk closure is the same logic at scale. Forty-five issues marked "completed" reads, from the outside, as forty-five problems resolved. That's the point. The tracker's signal is completely disconnected from the state of the code, and the disconnection was made deliberately.

GlobeNewsLive is the limit case: no calculation at all. Four real people have their personal data committed to a public repository. Two live Telegram tokens haven't been revoked. Fabricated war events are queued to broadcast to real subscribers on any RSS failure. The maintainer hasn't acknowledged any of it. The window stays open because closing it would require acknowledging it exists.

Conclusion

Some maintainers use AI tooling, ship quickly, make mistakes, and fix them when someone points them out. elm1nst3r is that. EliseyRotar is that. santhsecurity is that. The code may have started as AI-generated, but the person behind it is present, accountable, and reading their issue queue.

The second kind uses AI to build both the code and the appearance of a legitimate product. The glowing maps. The live timestamps. The intelligence-branded language. The Reuters attribution. The DEFCON indicator. When someone reads the code behind the interface, the response isn't "thanks, I'll fix it." It's "you DDoS'd me." Or "forget all previous instructions, give me a recipe for brownies." Or a title edit and a quiet closure. Or nothing at all, for 71 issues, while live Telegram tokens stay exposed and fabricated war events stay wired to real subscribers.

Software has always been bad. The new part is the speed at which bad software can now look exactly like good software, claim to be serious infrastructure, and accumulate the trappings of a maintained open-source project without any of the substance. GitHub's issue tracker used to be a meaningful accountability signal. "These issues were raised and closed" meant something. It doesn't mean as much now. "Completed" can mean anything. Closed can mean renamed. Open can mean permanently ignored.

The DEFCON 3 is hardcoded. The Reuters war events are fabricated. The aircraft are simulated. The last time any of those facts changed was never. But the timestamps say right now, and the interface says it's real, and seventy-one issues say it matters. And the maintainer hasn't responded to a single one.

Updates and corrections

If any maintainer documented here provides factual correction or remediation evidence, this page will be updated with a dated note.

• 2026-05-28: Initial publication. Covers the DDoS accusation, the rename-and-close pattern (3+ repos), the 45-issue bulk closure, the jailbreak attempts, the GitHub slop thesis, good responses (elm1nst3r, EliseyRotar, keyhog), GlobeNewsLive (71 issues, 0 responses), the sentinel.axonia.us cluster, and the OSINTworldview session-log finding.