[GH-ISSUE #3398] Security issue

gitea-mirror commented

2026-05-05 13:45:09 -06:00

Owner

Copy link

Originally created by @gaycomputers on GitHub (Apr 11, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3398

Bug Description

Hello, I believe an attacker can use an active frps session (one they did not set up). This exposes a lot of attack surface, both in the parsing/passing of packets of frps, and in the server such as DoS.

For example, I have a frps server running on a gateway. It is forwarding my traffic on the port I want to my server (a game).
An attacker could do multiple things such as:
1. after causing a crash or connection loss on my gameserver, tell frps to connect to their machine with the same port- this would then route all legitimate traffic to my gateway to the attackers machine.
2. request a new connection to start forwarding new traffic from a different port to the attackers machine
3. exploit a vulnerability they discovered in the parsing of a packet handled by frps

A good fix for this would be to implement some kind of authentication between frps and frpc. In keeping with the simplicity of frp, it could even be as simple as a Y/n prompt in the frps when a frpc tries to connect. There could be a handshake using a key for unattended setup (avoiding the Y/n prompt).

frpc Version

0.48.0

frps Version

0.48.0

System Architecture

linux/amd64

Configurations

Most example configurations are affected.

Logs

No response

Steps to reproduce

...

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @gaycomputers on GitHub (Apr 11, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3398 ### Bug Description Hello, I believe an attacker can use an active frps session (one they did not set up). This exposes a lot of attack surface, both in the parsing/passing of packets of frps, and in the server such as DoS. For example, I have a frps server running on a gateway. It is forwarding my traffic on the port I want to my server (a game). An attacker could do multiple things such as: 1. after causing a crash or connection loss on my gameserver, tell frps to connect to their machine with the same port- this would then route all legitimate traffic to my gateway to the attackers machine. 2. request a new connection to start forwarding new traffic from a different port to the attackers machine 3. exploit a vulnerability they discovered in the parsing of a packet handled by frps A good fix for this would be to implement some kind of authentication between frps and frpc. In keeping with the simplicity of frp, it could even be as simple as a Y/n prompt in the frps when a frpc tries to connect. There could be a handshake using a key for unattended setup (avoiding the Y/n prompt). ### frpc Version 0.48.0 ### frps Version 0.48.0 ### System Architecture linux/amd64 ### Configurations Most example configurations are affected. ### Logs _No response_ ### Steps to reproduce 1. 2. 4. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [X] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:45:09 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:45:13 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Apr 11, 2023):

It can be implemented through server plugin.

@fatedier commented on GitHub (Apr 11, 2023): It can be implemented through [server plugin](https://github.com/fatedier/frp#server-manage-plugins).

gitea-mirror commented

2026-05-05 13:45:14 -06:00

Author

Owner

Copy link

@Becods commented on GitHub (Apr 12, 2023):

Set token or oidc for your frps to ensure that an attacker does not forward your traffic to his machine without knowing your token.

7678938c08/conf/frps_full.ini (L79-L115)

Enable tls if necessary.

7678938c08/conf/frps_full.ini (L126-L131)

@Becods commented on GitHub (Apr 12, 2023): Set token or oidc for your frps to ensure that an attacker does not forward your traffic to his machine without knowing your token. https://github.com/fatedier/frp/blob/7678938c088c8d57367494ad53dd5c3b9e0cca35/conf/frps_full.ini#L79-L115 Enable tls if necessary. https://github.com/fatedier/frp/blob/7678938c088c8d57367494ad53dd5c3b9e0cca35/conf/frps_full.ini#L126-L131

gitea-mirror commented

2026-05-05 13:45:14 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (May 13, 2023):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (May 13, 2023): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

gitea-mirror referenced this issue

2026-05-05 14:47:32 -06:00

[PR #3327] [MERGED] web/frpc&frps: support dark mode #4724

No Branch/Tag specified