[GH-ISSUE #146] Attach from URL: download file and then attach like a local file? #122

New issue

Closed

opened 2026-05-07 00:20:13 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:20:13 +02:00

Owner

Originally created by @cmeis on GitHub (Feb 15, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/146

Right now attaching files from a URL just includes the URL, i.e. the ntfy client (app) will download the file from the linked URL.

There are use cases, where the app will not be able to download from the URL depending on where "it is" (network wise).
One example:
Our access control system is sending notifications when specific doors are opened.
On some doors it's also attaching an image from a security camera showing the door. If I now use the "attach from file" functionality to attach an image like (fictious URL) https://1.2.3.4/liveimage.jpg, this will only be shown in the app if 1.2.3.4 is reachable from the app.

In our case, you'll get the image as long as your in the local network.
As soon as your off site (with no active VPN connection) you won't get the image.
Starting VPN to download it afterwards isn't working, too - you would download a current image , not the image showing who entered the door a few minutes ago.

This could be solved by having an option for the "attach form url" attachments that instructs the ntfy server to download the file from URL to the server, and then send it like a file uploaded with the "attach local file" option.

Originally created by @cmeis on GitHub (Feb 15, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/146 Right now attaching files from a URL just includes the URL, i.e. the ntfy client (app) will download the file from the linked URL. There are use cases, where the app will not be able to download from the URL depending on where "it is" (network wise). One example: Our access control system is sending notifications when specific doors are opened. On some doors it's also attaching an image from a security camera showing the door. If I now use the "attach from file" functionality to attach an image like (fictious URL) https://1.2.3.4/liveimage.jpg, this will only be shown in the app if 1.2.3.4 is reachable from the app. In our case, you'll get the image as long as your in the local network. As soon as your off site (with no active VPN connection) you won't get the image. Starting VPN to download it afterwards isn't working, too - you would download a current image , not the image showing who entered the door a few minutes ago. This could be solved by having an option for the "attach form url" attachments that instructs the ntfy server to download the file from URL to the server, and then send it like a file uploaded with the "attach local file" option.

BreizhHardware

2026-05-07 00:20:13 +02:00

closed this issue
added the
server

enhancement
labels

BreizhHardware commented

2026-05-07 00:20:14 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 15, 2022):

This could be solved by having an option for the "attach form url" attachments that instructs the ntfy server to download the file from URL to the server, and then send it like a file uploaded with the "attach local file" option.

There is unfortunately no way to solve this problem without opening a giant security issue in the ntfy server, because it lets any user decide what server the ntfy server talks to. Assuming your suggested logic is implemented as Attach-Download, if I did curl -d "Attach-Download: http://127.0.0.1:2586/login.php" ntfy.sh/mytopic, the ntfy server would talk to itself on port 2586. You'd be able to effectively probe the internal network and ports of the ntfy server like this.

I actually had a similar behavior to this implemented and even deployed 😱 ("peaking", see github.com/binwiederhier/ntfy@e50779664d and https://github.com/binwiederhier/ntfy/issues/93) that I had to remove because it allowed people to download stuff from the local server. You may say, can't you just disallow 127.0.0.1, but there are dozens of ways around that, so I removed it in the end.

I could see enabling this behavior as a feature flag, for couldn't you just download it in your script instead and then upload it to the ntfy server? Like this:

curl https://1.2.3.4/liveimage.jpg >  tmp.jpg
curl -T tmp.jpg ... ntfy.sh/bla

@binwiederhier commented on GitHub (Feb 15, 2022): > This could be solved by having an option for the "attach form url" attachments that instructs the ntfy server to download the file from URL to the server, and then send it like a file uploaded with the "attach local file" option. There is unfortunately no way to solve this problem without opening a giant security issue in the ntfy server, because it lets any user decide what server the ntfy server talks to. Assuming your suggested logic is implemented as `Attach-Download`, if I did `curl -d "Attach-Download: http://127.0.0.1:2586/login.php" ntfy.sh/mytopic`, the ntfy server would talk to itself on port 2586. You'd be able to effectively probe the internal network and ports of the ntfy server like this. I actually had a similar behavior to this implemented and even deployed :scream: ("peaking", see https://github.com/binwiederhier/ntfy/commit/e50779664d8fd662fc38b17bfcd666c888f7d82c and https://github.com/binwiederhier/ntfy/issues/93) that I had to remove because it allowed people to download stuff from the local server. You may say, can't you just disallow 127.0.0.1, but there are dozens of ways around that, so I removed it in the end. I could see enabling this behavior as a feature flag, for couldn't you just download it in your script instead and then upload it to the ntfy server? Like this: ``` curl https://1.2.3.4/liveimage.jpg > tmp.jpg curl -T tmp.jpg ... ntfy.sh/bla ```

BreizhHardware commented

2026-05-07 00:20:14 +02:00

Author

Owner

@cmeis commented on GitHub (Feb 15, 2022):

Yeah, thought of that after hitting the sen button 🙄.
Used together with access control the risk might be manageable, but I get it. I just had hoped to get around doing it on my side, as this won't work in the environment without additional things.

Perhaps making it an option to allow this behaviour for write access controlled topics would be a compromise? Obviously only relevant for self-hosted servers....

@cmeis commented on GitHub (Feb 15, 2022): Yeah, thought of that after hitting the sen button 🙄. Used together with access control the risk might be manageable, but I get it. I just had hoped to get around doing it on my side, as this won't work in the environment without additional things. Perhaps making it an option to allow this behaviour for write access controlled topics would be a compromise? Obviously only relevant for self-hosted servers....

BreizhHardware commented

2026-05-07 00:20:14 +02:00

Author

Owner

@binwiederhier commented on GitHub (Mar 12, 2022):

@cmeis What are we gonna do with this ticket? I feel like this should be solved outside of ntfy like I described above (download + upload to ntfy). Given that you have put so much work into testing ntfy I feel like I owe you one, so if you want this, I'll implement it for you behind a feature flag (default off). You decide :-D

@binwiederhier commented on GitHub (Mar 12, 2022): @cmeis What are we gonna do with this ticket? I feel like this should be solved outside of ntfy like I described above (download + upload to ntfy). Given that you have put so much work into testing ntfy I feel like I owe you one, so if you want this, I'll implement it for you behind a feature flag (default off). You decide :-D

BreizhHardware commented

2026-05-07 00:20:14 +02:00

Author

Owner

@cmeis commented on GitHub (Mar 12, 2022):

No, don't do it.
Too much security implications, and I can easily work around locally!

⁣--
Christian

Am 12. März 2022, 22:41, um 22:41, "Philipp C. Heckel" @.> schrieb:
@. What are we gonna do with this ticket? I feel like this should

be solved outside of ntfy like I described above (download + upload to
ntfy). Given that you have put so much work into testing ntfy I feel
like I owe you one, so if you want this, I'll implement it for you
behind a feature flag (default off). You decide :-D

--
Reply to this email directly or view it on GitHub:
https://github.com/binwiederhier/ntfy/issues/146#issuecomment-1065969151
You are receiving this because you were mentioned.

Message ID: @.***>

@cmeis commented on GitHub (Mar 12, 2022): No, don't do it. Too much security implications, and I can easily work around locally! ⁣-- Christian Am 12. März 2022, 22:41, um 22:41, "Philipp C. Heckel" ***@***.***> schrieb: ***@***.*** What are we gonna do with this ticket? I feel like this should >be solved outside of ntfy like I described above (download + upload to >ntfy). Given that you have put so much work into testing ntfy I feel >like I owe you one, so if you want this, I'll implement it for you >behind a feature flag (default off). You decide :-D > >-- >Reply to this email directly or view it on GitHub: >https://github.com/binwiederhier/ntfy/issues/146#issuecomment-1065969151 >You are receiving this because you were mentioned. > >Message ID: ***@***.***>