{
  "id": "allium-system-access",
  "url": "https://ohshit.app/incidents/allium-system-access/",
  "title": "Allium discloses unauthorized system access and revokes API keys during platform recovery",
  "level": 3,
  "level_name": "sharted",
  "date": "2026-10-28",
  "date_is_approximate": false,
  "updated": "2026-11-07",
  "tags": [
    "Allium",
    "API keys",
    "SaaS"
  ],
  "ecosystems": [
    "cloud",
    "crypto"
  ],
  "summary": "Allium detected unauthorized access Oct 25 and revoked API keys and required a new password Oct 28. Datashares and Assistant recovered Nov 2, and MCP Nov 5. Uploaded-data access remains separate. On Nov 6 Allium reports independently validated containment. Customer-data impact is under investigation.",
  "splash": "Allium application and API customers, especially integrations using existing keys or uploaded tables",
  "wipe": "Replace revoked API keys as instructed, set a new password, enable MFA and check affected workflows before restarting",
  "in_the_wild": "yes",
  "source_exception": null,
  "cves": [],
  "fixed": [],
  "checklist": [
    {
      "title": "Replace revoked API keys through the official app",
      "hint": "Create a new key in Allium and update each integration’s secret store. If your Allium contact is issuing a key directly, follow the status notice and wait for it. Test a representative API request after updating configuration; a restored endpoint does not make the old key valid."
    },
    {
      "title": "Reset your password and enable MFA",
      "hint": "Use your existing official Allium bookmark to sign in and set a new password as instructed. Turn on multi-factor authentication. Review the direct customer notice and coordinate unusual activity with Allium support; do not infer that every stored credential or customer dataset was stolen."
    },
    {
      "title": "Validate data dependencies and service recovery",
      "hint": "Check status.allium.so before resuming jobs. The read notice says uploads and access to previously uploaded tables are disabled, so queries depending on those tables will fail; Allium Assistant was restored for all users November 2 at 16:22 UTC, and MCP was restored November 5 at 14:11 UTC. All-chain datashare delivery and historical verification were confirmed October 30, and that incident was marked resolved November 2. Validate your downstream jobs and affected interval; a stale verified_until timestamp alone does not establish missing data. These recoveries do not lift the uploaded-table restriction; public dashboard-link sharing is still being restored. Keep checking feature status and customer notices after containment validation."
    }
  ],
  "sources": [
    {
      "name": "Allium security statement",
      "url": "https://www.allium.so/blog/allium-security-update-incident-response-and-platform-recovery/",
      "says": "CEO Ethan Chan confirms unauthorized access detected October 25, direct notification and independent investigation. The November 6 update reports independent validation of containment and leaves customer-data impact open.",
      "primary": true
    },
    {
      "name": "Allium official status and recovery notices",
      "url": "https://status.allium.so/",
      "says": "October 28 security-reset notice requires new API keys/password; distinguishes restored core services from uploaded data, AI/MCP and ongoing datashare validation.",
      "primary": true
    },
    {
      "name": "Allium full datashare incident history",
      "url": "https://status.allium.so/incidents/dry5s6427nfb",
      "says": "October 30 confirms all-chain delivery and historical verification; November 2 at 10:38 EST marks this datashare incident resolved. Other feature restrictions and the security investigation are separate.",
      "primary": true
    },
    {
      "name": "Allium separate Explorer/API recovery notice",
      "url": "https://status.allium.so/incidents/fhl7h8hp4sfz",
      "says": "November 2 at 11:22 EST restores Assistant; November 5 at 09:11 EST restores MCP for all users. Public dashboard-link sharing remains pending; uploaded-table recovery is not announced.",
      "primary": true
    }
  ],
  "headline": null,
  "one_liner": null,
  "in_the_wild_note": "Allium confirms unauthorized access; customer-data impact remains unspecified.",
  "mitigation": null,
  "timeline": [
    {
      "date": "Oct 25, 2026",
      "title": "Allium detects unauthorized access, according to its later security statement"
    },
    {
      "date": "Oct 28, 2026",
      "title": "Recovery notice announces security resets and partial restoration",
      "body": "Existing API keys are being revoked; customers should create a new key or wait for one issued by their Allium contact. Password reset and MFA are recommended, while uploaded-data access and AI/MCP recovery remain restricted."
    },
    {
      "date": "Oct 30, 15:03 UTC",
      "title": "All-chain datashare delivery and historical verification confirmed",
      "body": "Allium says Snowflake, BigQuery and Databricks datashares passed historical checks for all chains across all regions."
    },
    {
      "date": "Nov 2, 15:38 UTC",
      "title": "Datashare incident marked resolved",
      "body": "This closes the datashare outage, not the security investigation or separate uploaded-data and AI/MCP restrictions."
    },
    {
      "date": "Nov 2, 16:22 UTC",
      "title": "Allium Assistant restored for all users; MCP recovery still pending",
      "body": "The separate Explorer/API recovery notice confirms Assistant restoration but says more features, including MCP, will follow. It does not lift the uploaded-table restriction or close the security investigation."
    },
    {
      "date": "Nov 5, 14:11 UTC",
      "title": "MCP restored for all users",
      "body": "The Explorer/API notice restores MCP; public dashboard-link sharing is still being brought back online. This does not announce uploaded-table recovery or completion of the security investigation."
    },
    {
      "date": "Nov 6, 2026",
      "title": "Allium reports independent validation of containment",
      "body": "The forensic investigation continues to determine the full scope and impact. Allium plans a summary once it concludes."
    }
  ],
  "body_markdown": "Allium’s security statement acknowledges access to some systems and says affected customers were notified directly. It does not identify the entry point, enumerate accessed customer data or provide a victim count. L3 reflects a developer-facing data provider’s confirmed intrusion and credential-reset requirements; it does not assert a mass data leak.\n\nOctober 25 is the detection date. The incident date here follows the October 28 public security-reset and recovery notice, rather than treating an earlier maintenance/outage message as proof of public breach disclosure. Core service restoration is not equivalent to complete recovery: uploaded tables, AI/MCP functions and datashare verification have separate status. No link to the Binance or other bridge incidents is established.\n\nThe November 2 resolution applies specifically to datashare service degradation. At 16:22 UTC on November 2, the separate Explorer/API notice subsequently restored Allium Assistant for all users while leaving MCP recovery pending. Neither update lifts the October 28 uploaded-table restriction. No new root cause, customer-data scope or final forensic report is published in this resolution.\n\nThe November 5 update at 14:11 UTC restores MCP for all users. Public dashboard-link sharing remains in recovery. MCP availability does not establish restored uploaded-table access, a final forensic conclusion or resolved customer-data scope.\n\nOn November 6, Allium said the independent security firm it engaged had validated its containment measures. The company is still determining the full impact and plans to publish its findings once the investigation is complete. The validation gives no new feature-recovery or customer-data determination."
}