In PKCE, i understand that code_verifier is used to generate a code challenge and later this code_verifier value is verfied by authorization server to complete PKCE process.
How sensitive this code_verfier value is? Does this value has to be kept secret? What all attacks can an adversary perform if this value is leaked?
The code_verifier is sensitive indeed: it is the mechanism by which the Client proves in the call to the token endpoint that it was the one that initiated the Authorization Request in the first place.
This value should be kept secret, also see below.
Leaking it would allow an attacker the impersonate the (public) Client in the call to the token endpoint of the Authorization Server, thus obtain tokens that were intended for the real Client.
Note that even when not using any (hashing) transformation on the code_verifier but send it as plain in the code_challenge in the authorization request, it would still make it difficult for an attacker who is able to intercept the callback to the Redirect URI since he would also have to intercept the outgoing request.
But in general the code_verifier should be hashed with SHA256 into the code_challenge so even when intercepting the request, the attacker is not able to deduce the code_verifier.
From the RFC Section 1:
OAuth 2.0 [RFC6749] public clients are susceptible to the authorization code interception attack.
In this attack, the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as inter- application communication within the client's operating system.
Once the attacker has gained access to the authorization code, it can use it to obtain the access token.
...
To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called "code verifier". A unique code verifier is created for every authorization request, and its transformed value, called "code challenge", is sent to the authorization server to obtain the authorization code. The authorization code obtained is then sent to the token endpoint with the "code verifier", and the server compares it with the previously received request code so that it can perform the proof of possession of the "code verifier" by the client. This works as the mitigation since the attacker would not know this one-time key, since it is sent over TLS and cannot be intercepted.
The crucial phrasing here is: "proof of possession of the 'code verifier' by the client. This works as the mitigation since the attacker would not know this one-time key, since it is sent over TLS and cannot be intercepted."
TL;DR:
The code challenge+verifier pair is the crucial thing that proves the client requesting the authentication token is the same as (or trusted by) the client who requested the authorization code in the first place. If the code verifier is leaked, then the attack mentioned here in the RFC (essentially a malicious app leveraging cross-talk to impersonate a legitimate app) is not mitigated, and thus the purpose of PKCE (to prevent such an attack) is thwarted.
