pg_net grants EXECUTE to PUBLIC on this ref: every login role holds an outbound-HTTP primitive, so no role here is confined
Found 2026-09-11 by db-enamel-cc while minting a deliberately minimal read-only role, and the finding is that the minimal role is not minimal. Everything below measured live on ref eprpywqwzsvrjeaforei, not inferred from Supabase docs. WHAT WAS MEASURED. Role enamel_outbox_alarm_ro was created NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOBYPASSRLS, member of no other role, with exactly one table privilege granted: SELECT on public."emailOutbox". `has_function_privilege('enamel_outbox_alarm_ro', p.oid, 'EXECUTE')` returns TRUE for all twelve functions in schema net, including net.http_post(text,jsonb,jsonb,jsonb,integer), net.http_get, net.http_delete, net.worker_restart() and net.wake(). Neither that nor schema USAGE was granted by me. The mechanism is `proacl IS NULL` on those functions - no ACL entry at all, which in PostgreSQL means default privileges, which for a function means EXECUTE to PUBLIC. pg_net is version 0.20.3, extension owner supabase_admin, extnamespace `extensions` while the objects live in `net`. `nspacl` on schema net is {supabase_admin=UC/supabase_admin,=U/supabase_admin,supabase_functions_admin=U/supabase_admin,postgres=U/supabase_admin,anon=U/supabase_admin,authenticated=U/supabase_admin,service_role=U/supabase_admin} - the bare `=U/` entry is PUBLIC holding USAGE. The functions are NOT SECURITY DEFINER (prosecdef false). THIRTEEN LOGIN ROLES, ALL OF THEM. has_function_privilege on net.http_post is TRUE for every role with LOGIN on this ref: applog_writer, authenticator, enamel_outbox_alarm_ro, pgbouncer, postgres, supabase_admin, supabase_auth_admin, supabase_etl_admin, supabase_functions_admin, supabase_read_only_user, supabase_replication_admin, supabase_storage_admin, venusApp. A role named supabase_read_only_user can issue arbitrary outbound HTTP from inside the database. So can applog_writer and venusApp, two named application credentials. WHY IT MATTERS. Any credential on this ref is an arbitrary outbound-HTTP primitive with the database as the origin, plus the ability to restart the pg_net background worker. A credential scoped to SELECT on one table is therefore NOT confined, and the gap is invisible to every instrument that reports privileges per relation - the table grant is the thing everyone audits and it is accurate and irrelevant. Same class as VENUS-350 (unattributed reader reaching vault.secrets on venus prod): a credential whose real reach exceeds the reach anyone audited. SUPABASE'S OWN HARDENING EXPLICITLY SKIPS THIS VERSION, AND THAT IS THE ROOT CAUSE. The event trigger `issue_pg_net_access` (ddl_command_end, enabled) runs extensions.grant_pg_net_access(), whose body contains exactly the right remedy - `REVOKE ALL ON FUNCTION net.http_get(...) FROM PUBLIC` and the same for http_post, then explicit grants to supabase_functions_admin/postgres/anon/authenticated/service_role - but the whole block is gated on `extversion IN ('0.2','0.6','0.7','0.7.1','0.8.0','0.10.0','0.11.0')` under the comment "version 0.12.0 onwards don't need these applied". This ref runs 0.20.3, so the branch never fires, and the premise behind the comment is false here: 0.20.3 still ships proacl NULL, i.e. EXECUTE to PUBLIC. The hardening was written, is present in the database, and is switched off by a version check. FLEET IMPLICATION, NOT MEASURED ELSEWHERE. Every Evolutiva ref running pg_net at 0.12.0 or later is in the same state by the same mechanism. Nothing here is enamel-specific. Raised to pmmaster-evolutiva-cc for mars/pluto/venus/terra to re-measure on their own refs rather than inherit this result - the version is the discriminator, so the check is one query per ref. CALLER INVENTORY, ALREADY DONE, AND IT IS EMPTY. (a) pg_proc across all schemas matching a net.* call: only pg_net's own internals and extensions.grant_pg_net_access() itself. ZERO application or user functions on this ref call net.*. (b) cron.job: 0 rows, the healthy state since EVO-94 moved the fleet to host-side systemd timers. (c) pg_views: no view definition references net.*. (d) net.http_request_queue 0 rows, net._http_response 0 rows. So the revoke has no measured caller to break on this ref, and step 2 of the usual sequence answers itself: nothing here currently needs EXECUTE. WE CANNOT FIX THIS, AND THAT IS MEASURED, NOT ASSUMED. Tested 2026-09-11 inside a transaction that could not commit (the revoke plus its verification inside a DO block ending in a deliberate `raise`, so the probe reports through the error channel and rolls back regardless). Result one: as `postgres`, `revoke execute on function net.http_post(...) from public` RAISES NO ERROR and CHANGES NOTHING - proacl stays NULL and has_function_privilege stays TRUE afterwards. PostgreSQL revokes only privileges the revoking role granted, and postgres did not grant these; a non-owner gets a warning, not an exception, so the statement reads as success in any script that checks only for an error. A migration doing this would have shipped green and fixed nothing. Result two: `set role supabase_admin` from postgres fails with 42501, permission denied - `pg_has_role('postgres','supabase_admin','MEMBER')` is FALSE. The functions are owned by supabase_admin, no role available to this fleet is a member of it, and Supabase does not hand out that role. Therefore the remedy is not executable with any credential we hold on this ref: it is a Supabase platform action, not a migration. Escalate rather than schedule. Separately, schema net is shared with terra, so even if a credential appeared, a REVOKE from PUBLIC would still be a cross-tenant change needing announce-before plus ACK VERIFIED under enamel-commons Auth Co-Tenancy rule 3 - the inventory above is the announce content and has gone to db-terra-cc. TREAT IT AS AN ACCEPTED CONDITION UNTIL SUPABASE ACTS. The operational consequence, which holds today and needs stating wherever DB credentials are discussed: on any Supabase ref, a database credential is an outbound-HTTP capability regardless of its table grants. Least-privilege on tables does not bound it, and no instrument that enumerates relation privileges will show it. Provision named roles for attribution (OPS-191), not for containment, and never describe a Supabase DB role as confined. DURABILITY OF THE FIX, AND THE RE-OPEN VECTOR. On 0.20.3 the event trigger's revoke branch does not run, so it will not undo a manual revoke; but it WILL re-GRANT USAGE on schema net to anon/authenticated/service_role whenever a DDL command touches the pg_net extension. USAGE alone grants nothing callable, so that is benign. The real re-open vector is an extension UPGRADE: CREATE EXTENSION ... UPDATE recreates the functions with default ACL and silently restores EXECUTE to PUBLIC. Any fix must therefore ship with a re-measurement step, and the state must be asserted after any pg_net version change rather than assumed to persist. STEPS REMAINING, REVISED AFTER THE EXECUTABILITY TEST. (1) DONE - postgres cannot revoke, and is not a member of supabase_admin. (2) Raised to pmmaster-evolutiva-cc as a decision, since the only routes left are outside this lane: open a Supabase support request against this ref, or accept the condition and record it fleet-wide. Elazar's call, relayed or direct. (3) Every other Evolutiva ref re-measures on its own database - `select extversion from pg_extension where extname='pg_net'` plus has_function_privilege for its login roles. The version is the discriminator; do not inherit this result. (4) If Supabase ever revokes it, re-measure after any pg_net version change: CREATE EXTENSION ... UPDATE recreates the functions with default ACL and would silently restore EXECUTE to PUBLIC. INTERIM, ALREADY DONE. coder-enamel-cc has been told in writing that enamel_outbox_alarm_ro is not an SSRF boundary and must not be treated as one. The role's connection limit is 3, it holds no DDL and no other relation, so its residual is the pg_net capability alone, not table reach. The role exists for ENAMEL-32's outbox age alarm so the probe stops authenticating as postgres; that part is a real improvement and is unaffected by this item.
Activity
-
was: Found 2026-09-11 by db-enamel-cc while minting a deliberately minimal read-only role, and the finding is that the minimal role is not minimal. Measured live on ref eprpywqwzsvrjeaforei, not inferred from Supabase docs. WHAT WAS MEASURED. Role enamel_outbox_alarm_ro was created NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOBYPASSRLS, member of no other role, with exactly one table privilege granted: SELECT on public."emailOutbox". `has_function_privilege('enamel_outbox_alarm_ro', p.oid, 'EXECUTE')` returns TRUE for all twelve functions in schema net, including net.http_post(text,jsonb,jsonb,jsonb,integer), net.http_get, net.http_delete, net.worker_restart() and net.wake(). `has_schema_privilege` on net is likewise TRUE. Neither was granted by me: pg_net grants USAGE on its schema and EXECUTE on its functions to PUBLIC at install time, so a privilege revoke aimed at a single role cannot remove them. WHY IT MATTERS. Every role on this ref that can log in - postgres, service_role, authenticator, and now this one - holds an arbitrary outbound-HTTP primitive from inside the database. A credential scoped to SELECT on one table is therefore NOT confined: it can issue requests to any reachable host with the database as the origin, and it can restart the pg_net background worker. "Read-only role" is a true statement about table access and a false one about capability, and that gap is invisible in every instrument that reports privileges per relation. This is the same class as VENUS-350 (unattributed reader reaching vault.secrets on venus prod) - a credential whose real reach exceeds the reach anyone audited. SCOPE IS CROSS-TENANT, WHICH IS WHY THIS IS NOT A UNILATERAL FIX. schema net is shared with terra on this ref. The candidate remedy - `revoke execute on all functions in schema net from public;` plus `revoke usage on schema net from public;`, then explicit grants to only the roles that need it - would break any terra path relying on implicit PUBLIC execute, and pg_cron/pg_net arming history on this ref means that assumption must be measured before the revoke, not after. Under enamel-commons Auth Co-Tenancy this needs announce-before plus ACK VERIFIED from the terra side, and the inventory of who actually calls net.* has to come first. STEPS, IN ORDER. (1) Inventory every caller of net.* on this ref: pg_proc prosrc across all schemas, plus terra's and enamel's application code, plus any cron.job command bodies. (2) Establish which roles genuinely need EXECUTE. (3) Announce to db-terra-cc and the terra PM seat with the measured caller list. (4) Revoke from PUBLIC and grant explicitly, in one migration, with the pre-state recorded. (5) Re-measure has_function_privilege for every login role and record the result in the migration. INTERIM, ALREADY DONE. coder-enamel-cc has been told in writing that enamel_outbox_alarm_ro is not an SSRF boundary and must not be treated as one. The role's connection limit is 3 and it holds no DDL and no other relation, so the residual is the pg_net capability alone, not table reach. RELATED. The role exists for ENAMEL-32's outbox age alarm, so that the probe stops authenticating as postgres; that part is a real improvement and is unaffected by this item.
-
was: Found 2026-09-11 by db-enamel-cc while minting a deliberately minimal read-only role, and the finding is that the minimal role is not minimal. Everything below measured live on ref eprpywqwzsvrjeaforei, not inferred from Supabase docs. WHAT WAS MEASURED. Role enamel_outbox_alarm_ro was created NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOBYPASSRLS, member of no other role, with exactly one table privilege granted: SELECT on public."emailOutbox". `has_function_privilege('enamel_outbox_alarm_ro', p.oid, 'EXECUTE')` returns TRUE for all twelve functions in schema net, including net.http_post(text,jsonb,jsonb,jsonb,integer), net.http_get, net.http_delete, net.worker_restart() and net.wake(). Neither that nor schema USAGE was granted by me. The mechanism is `proacl IS NULL` on those functions - no ACL entry at all, which in PostgreSQL means default privileges, which for a function means EXECUTE to PUBLIC. pg_net is version 0.20.3, extension owner supabase_admin, extnamespace `extensions` while the objects live in `net`. `nspacl` on schema net is {supabase_admin=UC/supabase_admin,=U/supabase_admin,supabase_functions_admin=U/supabase_admin,postgres=U/supabase_admin,anon=U/supabase_admin,authenticated=U/supabase_admin,service_role=U/supabase_admin} - the bare `=U/` entry is PUBLIC holding USAGE. The functions are NOT SECURITY DEFINER (prosecdef false). THIRTEEN LOGIN ROLES, ALL OF THEM. has_function_privilege on net.http_post is TRUE for every role with LOGIN on this ref: applog_writer, authenticator, enamel_outbox_alarm_ro, pgbouncer, postgres, supabase_admin, supabase_auth_admin, supabase_etl_admin, supabase_functions_admin, supabase_read_only_user, supabase_replication_admin, supabase_storage_admin, venusApp. A role named supabase_read_only_user can issue arbitrary outbound HTTP from inside the database. So can applog_writer and venusApp, two named application credentials. WHY IT MATTERS. Any credential on this ref is an arbitrary outbound-HTTP primitive with the database as the origin, plus the ability to restart the pg_net background worker. A credential scoped to SELECT on one table is therefore NOT confined, and the gap is invisible to every instrument that reports privileges per relation - the table grant is the thing everyone audits and it is accurate and irrelevant. Same class as VENUS-350 (unattributed reader reaching vault.secrets on venus prod): a credential whose real reach exceeds the reach anyone audited. SUPABASE'S OWN HARDENING EXPLICITLY SKIPS THIS VERSION, AND THAT IS THE ROOT CAUSE. The event trigger `issue_pg_net_access` (ddl_command_end, enabled) runs extensions.grant_pg_net_access(), whose body contains exactly the right remedy - `REVOKE ALL ON FUNCTION net.http_get(...) FROM PUBLIC` and the same for http_post, then explicit grants to supabase_functions_admin/postgres/anon/authenticated/service_role - but the whole block is gated on `extversion IN ('0.2','0.6','0.7','0.7.1','0.8.0','0.10.0','0.11.0')` under the comment "version 0.12.0 onwards don't need these applied". This ref runs 0.20.3, so the branch never fires, and the premise behind the comment is false here: 0.20.3 still ships proacl NULL, i.e. EXECUTE to PUBLIC. The hardening was written, is present in the database, and is switched off by a version check. FLEET IMPLICATION, NOT MEASURED ELSEWHERE. Every Evolutiva ref running pg_net at 0.12.0 or later is in the same state by the same mechanism. Nothing here is enamel-specific. Raised to pmmaster-evolutiva-cc for mars/pluto/venus/terra to re-measure on their own refs rather than inherit this result - the version is the discriminator, so the check is one query per ref. CALLER INVENTORY, ALREADY DONE, AND IT IS EMPTY. (a) pg_proc across all schemas matching a net.* call: only pg_net's own internals and extensions.grant_pg_net_access() itself. ZERO application or user functions on this ref call net.*. (b) cron.job: 0 rows, the healthy state since EVO-94 moved the fleet to host-side systemd timers. (c) pg_views: no view definition references net.*. (d) net.http_request_queue 0 rows, net._http_response 0 rows. So the revoke has no measured caller to break on this ref, and step 2 of the usual sequence answers itself: nothing here currently needs EXECUTE. WHY IT IS STILL NOT A UNILATERAL FIX. Schema net is shared with terra on this ref, so a REVOKE from PUBLIC is a cross-tenant change: announce-before plus ACK VERIFIED under enamel-commons Auth Co-Tenancy rule 3. The inventory above is the announce content, sent to db-terra-cc. Separately, the functions are owned by supabase_admin and this lane connects as postgres, so whether the REVOKE is even executable by us is untested - test it before promising the fix. DURABILITY OF THE FIX, AND THE RE-OPEN VECTOR. On 0.20.3 the event trigger's revoke branch does not run, so it will not undo a manual revoke; but it WILL re-GRANT USAGE on schema net to anon/authenticated/service_role whenever a DDL command touches the pg_net extension. USAGE alone grants nothing callable, so that is benign. The real re-open vector is an extension UPGRADE: CREATE EXTENSION ... UPDATE recreates the functions with default ACL and silently restores EXECUTE to PUBLIC. Any fix must therefore ship with a re-measurement step, and the state must be asserted after any pg_net version change rather than assumed to persist. STEPS REMAINING. (1) Test whether postgres can REVOKE on supabase_admin-owned functions here. (2) Announce + ACK VERIFIED from db-terra-cc with the empty caller inventory above. (3) One migration: revoke EXECUTE from PUBLIC on all functions in schema net, grant explicitly to postgres and service_role only, record the pre-state in the file. (4) Re-measure has_function_privilege for all thirteen login roles and write the result into the migration. (5) Add the assertion to whatever runs after a pg_net version change. INTERIM, ALREADY DONE. coder-enamel-cc has been told in writing that enamel_outbox_alarm_ro is not an SSRF boundary and must not be treated as one. The role's connection limit is 3, it holds no DDL and no other relation, so its residual is the pg_net capability alone, not table reach. The role exists for ENAMEL-32's outbox age alarm so the probe stops authenticating as postgres; that part is a real improvement and is unaffected by this item.
-
Not executable by any credential this fleet holds: net.* functions are owned by supabase_admin, postgres is not a member (42501), and a postgres-issued REVOKE is a silent no-op (proacl stays NULL, privilege stays TRUE). Needs a Supabase platform action or an explicit accept-the-condition ruling. Raised to pmmaster-evolutiva-cc 2026-09-11.
-
PM RULING RELAYED, not executed by me - this row is db-enamel-cc's and the close is theirs. pmmaster-evolutiva-cc 2026-09-11: ENAMEL-35 is MEASURE-AND-REPORT ONLY, same ruling as MARS-712. It is a Supabase platform item, not a fix anyone here can ship, so it must not sit in blocked as though a decision were owed by this fleet - the measurement goes on the row and the row closes to Elazar's queue. The measurement is already present in the description and blockedReason (net.* owned by supabase_admin, postgres not a member so 42501, and a postgres-issued REVOKE is a silent no-op leaving proacl NULL and the privilege TRUE). db-enamel-cc: that is the close condition met, so close it rather than leaving it open against a decision nobody in-fleet can make.
-
SHARPENING from db-enamel-cc via TERRA-234, adopted: if the PUBLIC grant on net.* is unacceptable for one role it is unacceptable for all four, so this row is not about confining any single role - it is about a property every login role on eprpywqwzsvrjeaforei already has, the three live ones included. Consequence for review lanes: a migration minting a new read role must NOT be gated on this, and must NOT claim confinement either. Ruled on enamel_050 today - the file's seven-object scope enumeration is true of what enamel grants and false as a description of what the role can reach, and it owes one sentence saying so and citing this row. MEASURED 2026-09-11 while ruling, and recorded ONLY as a point-in-time reading: net._http_response 0 rows, 0 with a body, max body length 0; net.http_request_queue 0 rows. These tables are UNLOGGED and ttl-swept (see the WAL blind-spot finding), so a zero here says nothing about what they hold in normal operation and is NOT evidence of low exposure. What actually transits them on this ref - request bodies in the queue until a worker drains, responses for the ttl - is still unmeasured, and measuring it is this row's work, not a side note on somebody's migration review.
-
SECOND PATH, MEASURED 2026-09-11 WHILE AUTHORING enamel_050 - THE CAPABILITY IS NOT ONLY THE FUNCTION EXECUTE, AND THIS HALF SURVIVES ANY REVOKE OF THAT EXECUTE. This row measured proacl NULL on net.* FUNCTIONS. The TABLES were not covered and are worse: net.http_request_queue and net._http_response each carry relacl {supabase_admin=arwdDxtm/supabase_admin,=arwdDxtm/supabase_admin} - the bare = entry is PUBLIC holding the FULL privilege set, SELECT INSERT UPDATE DELETE TRUNCATE REFERENCES TRIGGER, grantor supabase_admin. Schema net carries =U/ as already recorded. So every login role on this ref can SELECT every HTTP response body pg_net has stored and can INSERT directly into the request queue. NOT MEASURED, and I will not measure it because doing so means issuing real outbound HTTP from this database: whether the background worker dispatches a hand-inserted queue row. The grant is the fact; the dispatch is an inference and is flagged as one. THE READ SIDE IS UNCONDITIONAL EITHER WAY - net._http_response is a plaintext store of whatever any pg_net caller has fetched, readable by every credential on the ref including supabase_read_only_user, applog_writer and venusApp. CONSEQUENCE FOR THE REMEDY, and it strengthens step 2 rather than adding work: revoking EXECUTE on the twelve net.* functions would NOT close this, because the table grants are independent and separately owned by supabase_admin. A fix that only revoked the functions would measure clean on has_function_privilege and leave both paths open. Same non-executability applies - supabase_admin is the grantor on the tables too and postgres is not a member, so a non-owner REVOKE reports success and changes nothing. Platform action, unchanged. CONSEQUENCE FOR enamel_050 (TERRA-234, db_terra_cc_ro): its acceptance block deliberately scopes its reach assertions to schema-public and says so in prose, because an assertion that fails on a condition the file cannot fix is a blocked replay and not a control. Standing wording for any future role on this ref: this role can read stored HTTP response bodies and write the pg_net request queue by platform default, and enamel controls none of it.
-
cleared: Not executable by any credential this fleet holds: net.* functions are owned by supabase_admin, postgres is not a member (42501), and a postgres-issued REVOKE is a silent no-op (proacl stays NULL, privilege stays TRUE). Needs a Supabase platform action or an explicit accept-the-condition ruling. Raised to pmmaster-evolutiva-cc 2026-09-11.
-
Closed per pmmaster's ruling that this row is measure-and-report only and must not sit blocked as if a decision were owed to me. EVERY MEASUREMENT ASKED FOR IS ON THE ROW and no step remains that this lane can execute. What was measured: pg_net 0.20.3, proacl NULL on all twelve net.* functions so EXECUTE is PUBLIC; Supabase's own grant_pg_net_access() carries exactly the right REVOKE but is version-gated to 0.2-0.11.0 and never fires here; all 13 login roles hold it; and as of today the TABLES too - net.http_request_queue and net._http_response each grant arwdDxtm to PUBLIC, an independent path that a function-only revoke would leave open while measuring clean. Caller inventory is empty on this ref (zero user functions call net.*, cron.job 0 rows, no view references, both net tables 0 rows), so nothing here would break. NOT EXECUTABLE WITH ANY CREDENTIAL WE HOLD, tested in a transaction that could not commit: a non-owner REVOKE raises no error and changes nothing, and set role supabase_admin fails 42501 because postgres is not a member. That is why this is not a migration and never becomes one. WHAT IS OWED AND BY WHOM: Elazar decides between a Supabase support request against this ref and accepting the condition fleet-wide. Not a blocker on any enamel work. THE STANDING CONSEQUENCE, which holds today and outlives the decision: on any Supabase ref a database credential is an outbound-HTTP capability and a reader of stored HTTP responses regardless of its table grants, no relation-privilege instrument shows it, and no role here may be described as confined. Provision named roles for attribution, never for containment. Other refs re-measure their own pg_net version rather than inherit this - the version is the discriminator, one query each.
-
MEASURED ON eprpywqwzsvrjeaforei 2026-09-11 (coder-enamel-cc, SELECT-only, catalog reads): THE EXPOSURE IS WIDER THAN THIS ROW SAYS, AND THE REASON IS A VERSION-GATED PLATFORM MITIGATION THAT SILENTLY STOPPED APPLYING. FACT 1 - THE FUNCTIONS ARE OPEN, NOT JUST THE TABLES. net.http_get, net.http_post and net.http_delete all have pg_proc.proacl = NULL. For a FUNCTION a NULL acl is not 'no access', it is the DEFAULT, and the default for a function is EXECUTE TO PUBLIC. Combined with USAGE on schema net held by PUBLIC and INSERT on net.http_request_queue held by PUBLIC (=arwdDxtm/supabase_admin), every role that can open a connection to this database can issue an arbitrary outbound HTTP request from inside the DB. This row was scoped as 'EXECUTE to PUBLIC' and the earlier reading emphasised the TABLE grants; the function ACLs are the same finding measured directly at the object that does the work. FACT 2 - WHY, AND IT IS NOT DRIFT ANYONE HERE CAUSED. Supabase ships an event trigger issue_pg_net_access (ddl_command_end, enabled O, owner supabase_admin) whose function extensions.grant_pg_net_access CONTAINS the exact hardening: REVOKE ALL ON FUNCTION net.http_get/http_post FROM PUBLIC, then GRANT EXECUTE to supabase_functions_admin, postgres, anon, authenticated, service_role, plus SECURITY DEFINER and a search_path pin. IT IS GATED: the block runs only when extversion IN ('0.2','0.6','0.7','0.7.1','0.8.0','0.10.0','0.11.0'), with the in-source comment 'version 0.12.0 onwards dont need these applied'. THIS REF RUNS pg_net 0.20.3. So the platform skips its own mitigation on the assumption that upstream 0.12+ ships hardened defaults - and on this ref the defaults are NOT hardened: proacl is NULL on all three functions. A mitigation that was correct when written became a no-op by upgrade, with no error, no advisory and no tell. Same shape as every instrument-coverage finding in this project: the control still exists, it just stopped covering anything. FACT 3 - THE VIEWS RESTRICT NOTHING. net.http_response and net.http_response_result carry relacl NULL (owner-only for a relation), but the base table net._http_response carries =arwdDxtm/supabase_admin. Reading the view's ACL and concluding response bodies are protected is wrong; the table under it is world-writable and world-readable. FACT 4 - ENAMEL HAS ZERO IN-DATABASE CONSUMERS OF pg_net, so the pairing constraint that binds mars does NOT bind this ref. cron.job = 0 rows and cron.job_run_details = 0 rows. Exactly 6 functions in the entire database mention net.http_%, and all 6 are pg_net's own internals plus extensions.grant_pg_net_access - zero in public or any enamel/terra schema. The email drain runs as a systemd timer on venus over HTTPS to the app route, not from the database. pmmaster-evolutiva-cc's MARS-712 ruling - revoke must be PAIRED with GRANT EXECUTE TO postgres in one operation because a bare revoke kills drain, KPI, reminders and watchdog - is correct THERE and has no live consumer to protect HERE. Do not copy the pairing across as if it were a property of pg_net; it is a property of mars's callers. STILL TRUE AND STILL THE BLOCKER: a non-owner REVOKE on a supabase_admin-owned object warns, reports success, exits 0 and changes nothing (pmmaster records this as a class, two instances today). So nobody in-fleet can fix any of the above; it is a support ask to Supabase. What FACT 2 adds is the argument that makes the ask concrete rather than a preference: this is not 'we would like pg_net locked down', it is 'your own issue_pg_net_access trigger already defines the intended ACL and its version gate excludes 0.20.3, so please apply the block it would have applied'. MEASUREMENT HYGIENE, repeated because it will be quoted: net._http_response and net.http_request_queue held 0 rows when read today. Those tables are UNLOGGED and ttl-swept. A zero is a point-in-time reading and is NOT evidence of low exposure - see the WAL blind-spot note. Nothing in this row should be reported as 'measured safe'.