RADIUS Issues

Response authenticator based Shared Secret Attack
Attacker observes a valid access request packet and the associated return packet(access-accept/access-reject packet), then launch offline exhaustive attack on the shared secret.
They can guess shared secret by pre-compute MD5(Code+ID+length+RequestAuth+Attributes) and resume the hash once.

User-Password Attribute Based Shared Secret Attack

Attacker observes the traffic and try to authenticate to client with a known password, and capture the resulting Access-Request packet and XOR the User-password attribute with the password they provided to client. This results in the value of MD5(S+RA). RA is known in the client request packet, so attacker can launch offline exhaustive attack to get shared secret.

User-Password Based Password Attack
As the previous attack method, attacker can get the value of MD5(S+RA), and replay the modified access request packet as pretending a client. If server dosen't impose user based rate limits, this will allow the attacker to get the correct password.

Request Authenticator Based Attacks
The security of RADIUS depends on the generation of the RA(Request Authenticator)  field, but a lot of implementations using poor PRNG(pseudo random number generation) to generate the RA. If the client uses a PRNG that repeats values (or has a short cycle), the protocol ceases to provide the intended level of protection.

These attacks require the attacker to cause client to produce a particular identifier value. An attacker can insert a series of extra requests to the client, forcing the desired identifier. Even if the identifier were not generated in a readily attackable way, it would still only increase the work factor by 256 times.

Passive User-Password Compromise Through Repeated Request Authenticator
Build dictionary RA--User Password Attribure
If the attacker can sniff the traffic between the RADIUS client and the RADIUS server, they can passively produce a dictionary of Request Authenticators, and the associated (protected) User-Password attributes. If the attacker observes a repeated Request Authenticator, they can remove any influence of the Shared Secret from the first 16 octets of the passwords by XORing the first 16 octets of the protected passwords together. This yields the first 16 octets of the two (now unprotected) user passwords XORed together.

Active User-Password Compromise through Repeated Request Authenticators
Build dictionary RA--MD(S+RA)
Attacker authenticate many times using known passwords and intercept the generated Access-Request packets, extracting the RA and user-password attribute. Then XOR the known password with user-password attribute and be left with the MD5(S+RA) value. Finally, the attacker generates a dictionary of RA and associated MD5(S+RA) value.
Attacker can use this dictionary(RA--MD(S+RA)) to recover the first 16 octets from the protected region of the user password, since c1=p1 XOR MD5(S+RA).

Replay of Server Responses through Repeated Request Authenticators

Using dictionary RA--ID--associate server response

Attacker observe the client request, check RA and ID from the dictionary, then pretend as server the return the associate response to client.

DOS arising from the prediction of the Request Authenticators
Build dictionary predict RA values and associated server response, then response the client's valid request with access-reject packets, implement DOS.