Let's assume that I have the client secret of an application legit.app.org, and I can create a malicious application bad.app.org, with the issuer being oidc.app.org.
If I can convince a user to connect to bad.app.org using oidc.app.org I will be able to receive the tokens for this user associated with the legit.app.org credential. So If I use those tokens to connect to legit.app.org I will be able to impersonate the user.
Thankfully, there's a second layer of protection which is that the legit.app.org will have to register valid redirect_uris. Requests usign legit.app.org client_id/client_secret will have to use one of those registered redirect_uri, and the auth server is supposed to do an exact match. So with bad.app.org I'll also have to somehow "control" a redirect_uri considered as valid for the client_id/client_secret of legit.app.org to be able to intercept valid tokens.
Note that most of the auth services allow to either revoke client_secret and get a new one. Last but not least, if somehow you need to include a client_secret in an unsafe app like a SPA or mobile app, the solution is to use PKCE instead of regular client_secret.
PS: forgot to add that if you use HS256 instead of RS256 to sign the token id, it's the client secret which is used to sign the id token. See https://openid.net/specs/openid-connect-core-1_0.html#Signing. So basically you can emit falsely signed id tokens and if the client accept symmetric signed keys with no iss check, you can impersonate anybody. Obviously that's why you shouldn't use JWT authentication with symmetric algorithm
