# Web2py Vulnerability Research Notes

## Findings So Far

### What We're Looking For
- A NEW 0-day vulnerability in web2py v3.1.1
- Similar to react2shell pattern: unsafe deserialization leading to RCE
- Must allow executing `/readflag` to get flag from `/root/flag.txt`

### Code Analysis Complete

#### 1. Template Rendering (✓ Analyzed)
- Template files: `web2py/gluon/template.py`, `web2py/gluon/compileapp.py`
- Uses yatl library for template parsing
- Templates are compiled to Python code via `compile2()` and executed in restricted environment
- **Not the vulnerability**: User input doesn't directly flow into template compilation

#### 2. eval/exec/compile Usage (✓ Analyzed)
Found several eval/exec calls:
- `compileapp.py:632`: `eval_key = eval(key)` - Used in testing, accessing symbols from globals
- `restricted.py:214`: `exec(ccode, environment)` - Executes compiled code in restricted env
- `languages.py:101`: `eval(text, {}, {})` - In `safe_eval()`, processes language files
- `scheduler.py:529`: `eval(task.function)` - Scheduler task execution (internal, not HTTP accessible)

**Not the vulnerability**: These don't accept direct user input

#### 3. Error Handling (✓ Analyzed)  
- Errors trigger `RestrictedError` which is logged via ticket system
- `ajax_error_500` JavaScript variable contains URL with request params
- **Tested**: Proper JSON encoding prevents XSS (`\u003c` for `<`, etc.)
- **Not the vulnerability**: No injection possible in error messages

#### 4. Deserialization (✓ Partially Analyzed)
Found pickle usage in:
- `restricted.py:105,111`: Loading error tickets (from disk/DB, not user input)
- `globals.py:1101,1166`: Session deserialization
  - File-based: `pickle.load(response.session_file)` from server-side file
  - DB-based: `pickle.loads(row["session_data"])` from database
  - Session ID is validated: `response.session_client != oc` check exists
  - **Not directly exploitable**: Session data comes from server storage, not cookies

- `utils.py:174,234`: `pickle.loads(data)` - Need to check where this is called

#### 5. JSON/Request Processing (✓ Analyzed)
- `globals.py:257-290`: `parse_post_vars()` handles JSON
- Uses `json_parser.load(body)` - Python's standard json library
- **Not the vulnerability**: No unsafe deserialization in JSON parsing

### Areas Still To Investigate

1. **Utils.py pickle.loads()**: 
   - Line 174 and 234 use `pickle.loads(data)`
   - Need to trace back where `data` comes from
   - Could this accept user input?

2. **Admin Interface**: 
   - Check if any admin endpoints are accessible without auth
   - Look for code execution features in admin app

3. **Special Endpoints**:
   - Generic views (.json, .xml) - already tested, return 404
   - XMLRPC endpoints
   - Service decorators (@service.json, @service.jsonrpc, etc.)

4. **Cache System**:
   - `cache.py:367,404`: Uses pickle.load() for file cache
   - Check if cache can be poisoned

5. **Contrib Modules**:
   - `contrib/spreadsheet.py`: Has pickle.loads
   - `contrib/redis_cache.py`: Has pickle.loads  
   - Other contrib modules might have vulns

### Key Insight from React2Shell
React2Shell (CVE-2025-55182) exploited **unsafe deserialization** in React's Flight protocol.
The pattern: 
- User sends crafted payload  
- Server deserializes it without validation
- Gadget chain leads to RCE

**For web2py, we need to find**:
- An endpoint that accepts serialized data from user
- The serialized data gets deserialized (pickle.loads, eval, etc.)
- No proper validation before deserialization

### Next Steps
1. Trace `utils.py` pickle.loads() calls
2. Examine all @service decorator endpoints
3. Check welcome app controllers for any user input -> eval/exec flows
4. Look at import functionality (might deserialize uploaded files)
5. Test XMLRPC/JSONRPC endpoints

### Test Ideas
- Send pickled payload as POST data with different content-types
- Try uploading files with pickle payloads
- Test cache poisoning
- Check if any endpoint accepts base64 encoded pickle data