I’ve seen several projects like this that offer a network server with access to these Apple models. The danger is when they expose that, even on a loop port, to every other application on your system, including the browser. Random webpages are now shipping with JavaScript that will post to that port. Same-origin restrictions will stop data flow back to the webpage, but that doesn’t stop them from issuing commands to make changes.

Some such projects use CORS to allow read back as well. I haven’t read Apfel’s code yet, but I’m registering the experiment before performing it.

▲

brians 2 hours ago | parent | next [-]

They offer it as an option but default it to false! This is still a --footgun option but it’s the least unsafe version I’ve seen yet! Well done, Apfel authors.

	▲	franze an hour ago \| parent [-]
		thx for the report - a totally valid attack vector i was not aware of before, should be fixed https://github.com/Arthur-Ficial/apfel/releases/tag/v0.6.23 - see also new https://github.com/Arthur-Ficial/apfel/blob/main/docs/server...

▲

stingraycharles 2 hours ago | parent | prev | next [-]

I don’t think many browsers will allow posting to 127.0.0.1 from a random website. What’s the threat model here?

▲

layer8 an hour ago | parent | next [-]

Restricting such access it is still a work in progress: https://wicg.github.io/local-network-access/

▲

brians 2 hours ago | parent | prev [-]

I think any browser will allow it but not allow data read back.

	▲	btown an hour ago \| parent \| next [-]
		FWIW this was the status quo (webpage could ping arbitrary ports but not read data, even with CORS protections) - but it is changing. This is partially in response to https://localmess.github.io/ where Meta and Yandex pixel JS in websites would ping a localhost server run by their Android apps as a workaround to third-party cookie limits. Chrome 142 launched a permission dialog: https://developer.chrome.com/blog/local-network-access Edge 140 followed suit: https://support.microsoft.com/en-us/topic/control-a-website-... And Firefox is in progress as well, though I couldn't find a clear announcement about rollout status: https://fosdem.org/2026/schedule/event/QCSKWL-firefox-local-... So things are getting better! But there was a scarily long time where a rogue JS script could try to blindly poke at localhost servers with crafty payloads, hoping to find a common vulnerability and gain RCE or trigger exfiltration of data via other channels. I wouldn't be surprised if this had been used in the wild.
	▲	airza 2 hours ago \| parent \| prev \| next [-]
		There is a CORS preflight check for POST requests that don't use form-encoding. It would be somewhat surprising if these weren't using JSON (though it wouldn't be that surprising if they were parsing submitted JSON instead of actually checking the MIME-type which would probably be bad anwyay)
	▲	mememememememo 2 hours ago \| parent \| prev [-]
		Isn't there a CORS preflight check for this? In most cases. I guess you could fashion an OG form to post form fields. But openai is probably a JSON body only. The default scenario should be secure. If the local site sends permissive CORS headers bets may be off. I would need to check but https->http may be a blocker too even in that case. Unless the attack site is http.

▲

snarkyturtle 28 minutes ago | parent | prev | next [-]

Noting that there's an option to require a Bearer token to the API

▲

robotswantdata an hour ago | parent | prev [-]

Keep seeing similar mistakes with vibe coded AI & MCP projects. Even experienced engineers seem oblivious to this attack vector