` The unhappy path, in vulnerable versions up to and including 0.9.80, detects the error and returns without explicitly terminating the request handler's execution flow.
That distinction โ returning versus terminating โ sounds like pedantry until you see what sits below it in the call stack. The error handler is coupled to the session creator. The middleware ordering places the error handler upstream of the route handler's continuation logic. So the error gets absorbed, the request context persists, and the code falls through into the branch that issues a session token. The attacker's browser receives a Set-Cookie header containing a valid, signed, authenticated session for the Mage application.
Stop and sit with that. The attacker never authenticated. They sent a request with a malformed provider parameter. The server responded with an identity.
From that session, [Confidence: High] the attacker can enumerate connected data sources. Mage's entire purpose is to hold connection configurations for external systems โ that is what a data pipeline orchestrator does. It stores S3 credentials with IAM permissions scoped to whatever the deploying team granted. It stores Snowflake account passwords or key-pair auth material for the warehouses it queries. It stores Salesforce OAuth tokens so it can pull CRM data on a schedule. It stores ML workflow secrets โ model registry tokens, Hugging Face credentials, feature store API keys, experiment tracking auth. Every one of these is a credential object sitting in a configuration store that a legitimately authenticated session can read.
One malformed request. All credentials. This is the actual math of the vulnerability, and it is why I keep insisting that we stop treating data orchestration tools as productivity software and start treating them as credential aggregation points.
I want to be precise about why this class of defect reproduces, because the Mage advisory is going to be treated as a singular event and it is not. The CWE classification โ 390 โ is doing real work here. It tells you that the root cause is not a missing if statement in a provider validation function. It tells you that the development team's error handling model across the authentication subsystem permits non-terminal error branches. That model, once established, propagates. It propagates to the token refresh flow, where a failed refresh should invalidate the session but may instead continue with the stale token. It propagates to the state parameter validation, where a mismatched state โ which exists specifically to prevent CSRF in the OAuth flow โ might produce an error that gets logged without aborting the callback. It propagates to PKCE downgrade handling, where a client that presents a missing code_verifier might trigger an error path that resumes with the authorization code anyway.
The double-PR structure of the fix is the tell. PR #6204 and PR #6205. [Confidence: High] Two pull requests means two code paths. If this were a single validation bug, there would be one patch. There are two, which means the fail-open pattern existed in at least two distinct branches within the OAuth handling logic. And when a team fixes two instances of a pattern, the honest question is: how many branches did they not audit?
When I audit similar tools, I run a simple mental checklist that I'd encourage every team running Mage โ or Airflow, or Dagster, or Prefect, or Superset โ to adapt for their own codebase. For each authentication error branch, ask: does this branch return without a status code? Does it log and continue? Does it set a request attribute that a downstream middleware reads as "authenticated"? Does it fall through to a shared session creation function? In Airflow, the OAuth flow goes through Flask-AppBuilder's security manager, which has a mature error model โ but mature does not mean immune, and the Flask-AppBuilder history shows authentication CVEs of its own. In Dagster, the authentication layer is newer, thinner, and more likely to have inherited the same optimistic-pattern problem. [Confidence: Medium] In Prefect, self-hosted deployments inherit Prefect Cloud's auth assumptions in ways that have not been comprehensively audited. [Confidence: Medium]
There is a deeper structural reason this happens in the data tooling category specifically, and it's the same reason I've argued for years that the "liquidity fragmentation" narrative in DeFi is a manufactured problem: incentive structures produce the failures they reward. Data pipeline tools compete on integration count. Mage's landing page touts connectors to dozens of sources โ AWS, GCP, Azure, Snowflake, BigQuery, Redshift, Salesforce, Postgres, MySQL, MongoDB, Kafka, and on. Each connector requires testing. The test surface for a "does your Salesforce OAuth work" integration is a happy path: connect, authorize, pull data. The test surface for "what happens if the callback arrives with a bogus provider parameter" is a malicious-failure case, and malicious-failure cases are not on the roadmap. They are not in the acceptance criteria. They are not what users file issues about.
Meanwhile, the identity security teams at enterprises deploying these tools have a completely different mental model. They own Okta, they own the IdP, they configure SAML and SCIM and conditional access. They view authentication as their domain. And they are right โ insofar as the applications in question delegate auth to their IdP. But Mage's OAuth flow is not delegated. It's the tool's own implementation of the OAuth client role, sitting outside the IdP's enforcement perimeter. The IdP sees nothing. The EDR sees an HTTP request. The SIEM sees a callback. The fail-open bug lives precisely in the seam between two organizational domains, each of which is confident the other is covering it. [Confidence: High]
This is not a novel observation, but the Mage case makes it concrete in a way that deserves to be operationalized: the credential aggregation layer of the modern data stack is an unenumerated attack surface that sits beneath the jurisdiction of the identity security program and above the jurisdiction of the endpoint security program, and it is therefore nobody's problem until it is everybody's incident.
Now let me address the part of the disclosure cycle that I think was handled poorly by the community, because this is where my ENTP instinct for arguing with consensus kicks in.
The narrative that coalesced around this disclosure was "the tenth authentication vulnerability in twenty-one days." Read that number again. Ten in twenty-one days. It sounds like a systemic collapse. It reads like proof that the entire software industry has forgotten how to authenticate. And I want to be the person who says, carefully and with evidence: that number is a rhetorical device, not a statistical fact.
Here's the problem. To claim that ten authentication CVEs in twenty-one days demonstrates a systemic industry degradation, you need a baseline. What is the expected rate of authentication CVE disclosure across the same population of projects over a comparable window? Nobody measured it. What was the coverage of the reporting sources โ did the same researcher or team find all ten, or did ten different researchers happen to publish in the same window? Nobody checked. [Confidence: Medium] What fraction of those ten were in actively-maintained projects versus abandoned ones? Unclear.
A cluster of events is not evidence of a trend. It is evidence of a cluster. And in vulnerability research, clustering has a well-known cause: researcher attention is lumpy. When one skilled researcher decides to systematically audit OAuth callback handlers across a category of open-source projects, they will find many similar bugs in a short period โ because that is what systematic auditing produces. This is researcher bias, not industry collapse. The researcher audited a category they'd identified as under-tested, and the category was under-tested, and so the bugs poured out in a burst.
I'm not saying the bugs aren't real. I'm saying the framing matters, because the framing determines the response. If you believe the industry is collapsing, your response is to wait for the industry to fix itself and to treat each individual CVE as evidence of a coming catastrophe rather than as a specific defect in a specific system that specific people need to patch this week. If you believe the industry has an under-audited category that one researcher just enumerated, your response is to audit your own category โ your Dagster, your Prefect, your self-hosted Metabase โ because the category is real even if the collapse is fictional.
The most useful framing I have found is the one the analyst commentary itself eventually arrived at, in a footnote-like aside that deserved a headline: the number matters less than the checklist revision it forces.
What is the checklist revision? It is this. Your asset inventory classifies systems by user, by role, by data sensitivity, and by regulatory scope. It almost certainly does not classify systems by credential aggregation. A Mage instance is not sensitive because it contains sensitive data โ it is sensitive because it contains access to sensitive data at every connected downstream system simultaneously. [Confidence: High] The blast radius of a Mage compromise is not Mage; it is every system Mage touches. That is an entirely different risk model, and the fact that most organizations don't model it is why the Mage CVE is more dangerous in practice than its CVSS score โ which is already 9.8 โ would suggest.
Let me build the actual attack chain, the one that matters in a real enterprise, because this is where the story gets darker than the advisory.
An attacker scanning for Mage instances has a well-defined fingerprint. The Mage web UI serves a predictable set of assets, a recognizable title tag, a known JavaScript bundle structure. Shodan and Fofa indices contain these. [Confidence: High] An attacker with the CVE and a scanner does not need to be skilled; they need to have run Shodan. Once an instance is identified, the exploit is a single unauthenticated HTTP request to the callback endpoint with a malformed provider parameter. The server responds with a session cookie. The attacker sends that cookie in the next request and receives the Mage application UI in authenticated state.
From there the path branches. The obvious path: enumerate connections, export the credential material, then pivot externally โ into Snowflake with the stolen credentials, pulling the enterprise's analytical warehouse; into S3 with the stolen IAM keys, reading or exfiltrating every object in scoped buckets; into Salesforce with the stolen OAuth token, harvesting CRM records and using the Salesforce instance's own email capabilities as a phishing relay. [Confidence: High] Each of these downstream systems has its own privileges and its own audit trail, and each audit trail will record the activity as legitimate, because the credentials are valid. This is the central horror of credential-aggregation compromise: the theft looks like usage.
The subtler path is worse. Instead of exfiltrating, the attacker modifies the pipeline. Mage pipelines move data from sources to destinations. If the attacker modifies a pipeline to add a transformation, or to duplicate output to an attacker-controlled destination, the modified pipeline continues to operate, continues to produce reports, continues to feed dashboards. The analyst looking at a pipeline dashboard sees green. The modification is invisible in the data output because the original output is still produced โ it's just also produced somewhere else. This is the same principle as a malicious npm package that does its job correctly and also exfiltrates environment variables. The attack succeeds by not failing. [Confidence: Medium]
There is a further, nastier variant unique to ML pipelines: training data poisoning. Mage pipelines feed feature stores and model training. If an attacker has write access to a pipeline that produces training data, they can subtly alter the distribution of that data โ not randomly, but in a targeted way that biases a specific model behavior. The model trains on a biased distribution. The model's outputs diverge from ground truth in a direction the attacker chose. And because model performance metrics move within normal variance, the drift is detected only after it has already affected every downstream decision the model has influenced. [Confidence: Low] I want to flag that confidence carefully: I have no evidence that this happened in any Mage compromise. I'm describing the capability that the vulnerability exposed, not asserting that it was exercised. But the capability is real, and it is why the duration of exposure matters as much as the occurrence of exposure.
Which brings me to the forensic problem, and this is the part of the Mage case that I think is systematically underestimated.
When a session is created through this vulnerability, what does the log show? The request arrives at the callback endpoint. The OAuth library records an error. The application records session creation. The log line, from the perspective of a detection engineer writing a rule, looks like a user session beginning. There is no failed login. There is no brute-force pattern. There is no anomalous credential use. There is no "user attempted to authenticate with a provider that doesn't exist and then a session appeared." [Confidence: High] The log entry is structurally indistinguishable from a legitimate user completing OAuth login.
The consequence is that an organization that was compromised six months ago through this bug has no log signal that distinguishes the compromise from normal operation. No brute-force alerting will catch it โ because there was no brute force. No credential-stuffing detection will catch it โ because no credential was used. No impossible-travel check will catch it unless the attacker was geographically careless. The only detection post-hoc is to look for sessions whose creation timestamp does not correlate with an inbound OAuth redirect chain in the IdP's logs โ which requires comparing Mage session logs against IdP authentication logs, which most organizations do not do across these two systems. [Confidence: Medium]
This asymmetry of observability transforms a patching problem into a forensic problem. Patching takes a maintenance window. Forensics takes a different kind of project entirely: a retrospective reconstruction of session history, cross-referenced against external authentication sources, over an unknown exposure window whose start date is itself unknown.
The start date matters enormously, and it was, I think, the single biggest omission in the disclosure. When was the vulnerable code introduced? The advisory doesn't say, and that matters for three reasons. First, it defines the forensic window: if you don't know when the bug shipped, you don't know how far back to look. Second, it defines the exposure surface: every deployment created between the bug's introduction and the patch is a candidate. Third, it defines the incident response scope: if the window is longer, the probability that somebody found this before the researcher did increases, because a scanning opportunity that persisted for, say, three years is a much wider exposure than one that persisted for three months.
I cannot tell you the answer to that without the git history in front of me, and if you are responsible for a Mage instance, you should pull that history and answer it yourself. [Confidence: High] The point is the frame: an unknown introduction date is not a neutral absence of information. It is a reason to assume the worst window.
Let me now say something that will be uncomfortable for the open-source security community, and I'll say it because it is true and someone should say it in a piece about a vulnerability, not in a think piece about open source that nobody reads.
The Mage advisory itself is well-handled by open-source standards. It has a GHSA identifier. It has a fix in a specific commit. It has a PR pair. It has a clear version boundary at 0.9.80. The maintainers did the right thing. This is not a story about a team that ignored a report or shipped a fix silently or threatened a researcher. This is a story about a team that did everything right on the response side โ and whose software, up to the patched version, was nonetheless a perfectly clean unauthenticated entry into the data gold vault of every deploying organization.
Which is what makes it a category story rather than an incident story. The open-source security model assumes that disclosure will trigger patching, and that patching will close the window. That model works reasonably well when the software is a library in a handful of applications, and it works poorly when the software is an application whose entire purpose is to be the central credential custodian of the enterprise data stack. The model's success condition โ fast disclosure, fast fix โ does not guarantee the model's outcome โ restoration of the pre-vulnerability security posture โ because the outcome requires the deploying organization to also act, immediately, on information that arrives without an operational context to act on. "Upgrade to 0.9.80" is not the full fix. The full fix is upgrade, plus forensic audit, plus credential rotation, plus pipeline integrity verification, plus detection rule implementation. Nothing in the advisory says this. It cannot say this, because it's a vulnerability advisory, not a deployment runbook.
So let me write the runbook, because the commentary I'm drawing from had the substance of it embedded in operational recommendations that I want to elevate into the article proper.
The sourcing problem is being underweighted. The Feedly solution described the vulnerability as having no public proof of concept and characterized the exploitation status as unclear. A separate group, The Core Group, simultaneously claimed to have material enabling exploitation. [Confidence: Medium] These two claims are in direct tension and I have no way to resolve them from the outside. But the resolution doesn't matter for the defensive decision, because the defensive decision must be made under uncertainty and the asymmetry is stark. If you assume no PoC exists and you're wrong, you're breached. If you assume a PoC exists and you're wrong, you spent a weekend upgrading and rotating credentials. The asymmetry of consequence, not the certainty of the claim, should determine your posture. [Confidence: High] And this is precisely where most organizations default to optimism โ because assuming a PoC exists means work, and assuming it doesn't means not doing the work, and the not-doing-the-work option feels like a prudent "wait for more information" framing of a decision that is actually a bet.
The rotation problem is the same thing, deeper. If you patch Mage but do not rotate the credentials it holds, then an attacker who compromised you before you patched retains the credentials they extracted. Patching the door after the thief is already inside the house does nothing about the thief. The rotation must cover the credential material itself โ S3 IAM keys, Snowflake passwords or key pairs, Salesforce OAuth refresh tokens, ML pipeline secrets โ and the rotation must consider that an attacker with temporary access might have added a credential rather than only stealing one. New IAM users in the AWS account. New Snowflake service users. New Salesforce connected apps. The audit must look for additions, not only for anomalous use of existing credentials. [Confidence: High] This is the part that almost everyone skips, because the rotation of existing credentials is a checklist item and the enumeration of added credentials is a manual investigation, and the manual investigation is where the actual attacker persistence lives.
The isolation problem is the one with the shortest decision window and the least ambiguity. If you cannot patch a Mage instance today โ because of a frozen change window, because it's running an old version on a critical pipeline, because it's someone's pet process โ you can isolate it at the network layer. Mage instances typically need outbound access to their data sources and to their deployment infrastructure; they do not typically need to be reachable from the open internet except for their own UI and callback endpoint. Restricting inbound access to the Mage UI behind a VPN or a private-access gateway removes the exploit path entirely at the cost of a network change. This is the option that security teams forget in the rush to version inventory, and it is the one with the clearest immediate effect. [Confidence: High]
Now I want to pivot to the part of the analysis that is more interesting to me than the incident, which is what Mage tells us about the future of trust in the data layer.
I spent a lot of 2025 and 2026 arguing that the most interesting thing happening in crypto is not the tokens, it is the agent architectures โ the emergence of autonomous systems that hold assets and execute policy without continuous human authorization. And the more I think about Mage, the more I think the two conversations are the same conversation wearing different clothes.
An AI agent on-chain in 2026 holds a wallet and executes transactions according to a model. Its security model is: what can it do, and to whom, and under what constraints? The whole discipline of agent security is about bounding the authority of a system that has authority because it is trusted with the raw materials of authority.
Mage is a primitive version of the same architecture. It is an agent โ not in the AI sense, in the operational sense โ that holds credentials and executes data movement according to a schedule. Its security model is the same: what credentials does it hold, what can they do, under what constraints? And the whole of Mage security is, or should be, about bounding a system whose authority is the aggregate of every downstream system's authority.
The trust-through-defaults defect is the same defect in both cases. In the AI agent, it manifests as an agent that encounters an evaluation error in its policy engine and, because the policy engine returns no structured denial, proceeds to execute the action it was evaluating. In Mage, it manifests as a callback handler that encounters an error in its authentication flow and, because the error handler does not terminate the request, proceeds to create the session. The two bugs look different. The two bugs are the same bug. Both are expressions of an architectural assumption โ that error implies "continue with caution" rather than "halt absolutely" โ and both are catastrophic precisely because the systems involved hold raw authority.
I have said elsewhere that constructing new myths from the ashes of Luna was the discipline of narrative recovery after a collapse that looked total and was in fact specific. There is a version of that discipline for infrastructure security, and I want to name it: constructing new defaults from the ashes of the fail-open. The lesson of the Terra collapse was not that algorithmic stablecoins can never work; it was that social consensus cannot be assumed, it must be engineered. The lesson of the Mage CVE is not that OAuth callbacks are hard; it is that error handling is not a defensive afterthought, it is a primary security control, and a control that permits continuation after failure is not a control at all.
The operational translation is architectural, and it is the recommendation I would make to every team running any orchestration tool this year. When you configure a data pipeline, apply least-privilege to what it can reach. Scope the IAM policy โ not s3: on all buckets, but s3:GetObject on the specific prefix the pipeline actually reads. Scope the Snowflake role โ not SYSADMIN, but a custom role with SELECT privileges on the specific schemas the pipeline queries. Scope the Salesforce permissions โ not a full-access connected app, but a specifically scoped OAuth application with read-only access to the objects the pipeline pulls. [Confidence: High] The vulnerability's impact is not the vulnerability; the impact is the product* of the vulnerability and the accumulated authority of the compromised system. You cannot control the former. You can absolutely control the latter, and the fact that most deployments of most orchestration tools give the tool administrative credentials to every source it touches is the structural flaw that turns a bounded bug into an unbounded breach.
And here is where I want to push back against the instinct to turn this into a compliance exercise, because the compliance-driven response to Mage is going to be a questionnaire, and questionnaires do not fix fail-open.
Consider how GDPR Art. 32 will read Mage. "Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the riskโฆ the controller shall implement appropriate technical and organisational measures." If a controller had a Mage instance exposed and did not patch within a reasonable window after disclosure, that is arguably not "appropriate technical measures." Art. 33 โ 72-hour breach notification โ becomes live if an investigation concludes a session was created by an unauthenticated party. And here's the thing about Art. 33 that tracks directly with the forensic problem: the obligation is triggered when you become aware of a personal data breach, and awareness requires an investigation that can distinguish a breach from normal operation. [Confidence: Medium] If your session logs cannot distinguish unauthenticated session creation from legitimate OAuth flow, you cannot become aware, so you cannot trigger notification, so you are technically compliant and materially compromised. That is a governance failure dressed as compliance, and it is the kind of thing that becomes an enforcement action after a subsequent investigation reveals what the logs could not.
SOC 2 CC6.1 โ logical access controls โ will read this the same way. ISO 27001 A.8.8, technical vulnerability management, makes patch response time an audit artifact. PCI DSS 6.3, if the pipeline touches cardholder data environments. None of these frameworks are the fix. The fix is the fail-closed principle and the scoring of these systems by credential aggregation rather than by user count. The frameworks become the record of whether you did the fix, and if you did not do the fix, the framework becomes the record of the failure.
I want to close on the thing that most distinguishes my read of this event from the mainstream read of this event, and that thing is this: the Mage CVE is being treated as a security incident, and it is actually an economic story about where value now sits.
The traditional security mentality asks: what is the CVSS? What is the exploitability? What is the patch status? Those questions yield a bounded operational answer โ patch within N days, isolate if unable, rotate credentials, done. That is the playbook, and I have walked you through it, and it is correct as far as it goes.
The narrative mentality asks a different question: what does the existence of this bug tell us about the current distribution of value and trust in the system? And the answer to that question is: the highest-leverage attack surface in the enterprise is no longer the perimeter, no longer identity, no longer the database, and no longer the source code repository. It is the layer of middleware that holds credentials to all of those things at once, and it is the least scrutinized layer in the entire system โ because it is not the database, so it doesn't get a database security program; because it isn't the identity provider, so it doesn't get an identity security program; because it isn't the endpoint, so it doesn't get an endpoint security program; because it's open source, so it gets the assumptions people carry about open source, which is that the code is reviewed by developers who understand what it does.
I have spent my whole career refusing to price the narrative at face value โ refusing to accept "blockchain adoption is happening" without seeing the wallets, refusing to accept "Layer 2 scales Ethereum" without watching where the users actually go, refusing to accept "Terra failed because algorithmic stablecoins are impossible" without checking whether the failure was algorithmic or social. And what I want to say about the Mage moment is that it is a price discovery event โ not of any token, but of trust itself. We are discovering that we priced a whole class of infrastructure at the wrong value, because we priced it by the benefit it delivers โ the pipelines it runs, the time it saves, the integrations it enables โ and not by the authority it accumulates โ the credentials it holds, the data it reaches, the failure surface it opens.
The correct price is higher than what we paid. The bill for the underpricing arrived as a single GitHub advisory in the last week of a summer quarter, and it will keep arriving for a while, because the category was under-tested and the category was under-priced and those two facts are the same fact.
The work ahead is the same work the last cycle taught me: find the seam. Every serious vulnerability I have followed in the last five years has lived in a seam โ a place between two teams, two systems, two models, two categories โ where each side was confident the other side covered it and neither side actually did. Mage is a seam between the identity program and the data program. The AI agent trust problem is a seam between the model team and the security team. The DeFi governance problem is a seam between the protocol and the community. The seam is always where the bug lives, and the discipline of audit is the discipline of finding the seam before someone else does.
The commit is thirty-one characters. The bug lived for some window we are still trying to bound, in a class of software we are still learning to inventory, in a layer of the enterprise we are still learning to price. It is patched now. But the seam it exposed is not patched, and there is no advisory for seams.
What we discovered this summer is not that authentication can fail open. It is that we have been trusting a class of systems to defend the most valuable credentials in the enterprise with code that was never tested for the possibility that the attacker controls the error path โ and that we discovered this because one researcher thought to send a malformed request. The next malformed request is out there. The question is not whether it will be sent; the question is whether the systems it lands in have learned to distinguish "detected an error" from "created an authenticated session."
The data layer's job is to move information. It has accidentally become the custodian of the keys to everything. It's past time that the software that does the first job was built with the seriousness that the second job demands โ and that the organizations that deploy it scored it not by how productive it makes their pipelines, but by how much damage a single malformed request to its callback endpoint could do.
That is the narrative I would bet on. The other one โ the one about twenty-one days and ten CVEs and collapse โ is a story that feels like a trend and behaves like a cluster. The seam story is the one that keeps being true, cycle after cycle, and it is the one that tells you what to actually do on Monday morning.
Find your Mage instances. Look at what they can reach. Ask yourself what a session created without a password would be allowed to touch. Then fix the answer โ not because a compliance framework says so, but because the credentials sitting behind that session are the actual economic value of the company, and the software that holds them just demonstrated that it will hand them to anyone who asks the wrong way.
Constructing new defaults from the ashes of the fail-open. That's the work now. The ashes are still warm.
{
"title": "The Day Authentication Became a Suggestion: Inside Mage OSS and the Fail-Open Enlightenment",
"tags": [
"Mage OSS",
"OAuth Security",
"CWE-390",
"Fail-Open Design",
"Data Pipeline Security",
"Credential Aggregation",
"Supply Chain Security",
"Authentication Bypass",
"Open Source Infrastructure",
"Data Stack Threat Modeling"
],
"prompt": "Editorial illustration in a cold, precise, high-contrast style: an abstract data pipeline rendered as a vertical column of lightโglowing tubes and connection nodesโrunning through a darkened enterprise architecture. At the exact midpoint of the pipeline, a single small malformed request, depicted as a small fractured hex code, enters through a hairline crack in the structure. Below the crack, the pipeline splits into three luminous but unseen corridors leading to distinct vaults labeled only by geometric abstractions of cloud storage, a data warehouse, and a CRM. In the negative space between the three corridors, a translucent human silhouette is stepping through one, unopposed, holding a glowing key that has been silently emitted from the crack above. The upper portion of the image is overexposed with corporate light; the lower portion is cold and shadowed. Color palette: deep charcoal, cold cyan, and one single warm gold accent on the leaked key. Composition is architectural and restrainedโno clutter, no text, no clichรฉ hacker imagery, no figures in hoodies. Victorian-forensic precision meets contemporary infrastructure photography."
}